Requirements Management and Communication (BABOK KA)

49574 Views
27 Likes
0 Comments
Large software systems have a few hundred to thousands of requirements. Neither are all requirements equal nor do the implementation teams have resources to implement all the documented requirements. There are several constraints such as limited resources, budgetary constraints, time crunch, feasibility, etc., which brings in the need to prioritize requirements.
14031 Views
3 Likes
0 Comments

 Managers often ask me what return on investment (ROI) they can expect from the money they spend on training, process improvement, and tools for requirements engineering. I’d love to give them a nice, tidy answer—but I can’t. As with so many questions in software, the correct answer is, “It depends.” This article explores some of the factors that influence what ROI an organization can expect from better requirements.

15488 Views
6 Likes
0 Comments
In this article we discuss the benefits of using an appropriate template as the vehicle for delivering requirements. We also cover how a review and approval process tailored to stakeholders can help create the alignment needed to move a project forward.
55085 Views
39 Likes
0 Comments
The 3 Amigos (sometimes referred to as a “Specification Workshop”) is a meeting where the Business Analyst presents requirements and test scenarios (collectively called a “feature”) for review by a member of the development team and a member of the quality assurance team.
15941 Views
6 Likes
0 Comments

Software developers often want to freeze the requirements following some initial requirements work and then proceed with development, unencumbered with those pesky changes. This is the classic waterfall paradigm. It doesn't work well in most situations. It’s far more realistic to define a requirements baseline and then manage changes to that baseline. This article defines the requirements baseline and describes when to create one.

 
English (auto-detected) » English
 
 
English (auto-detected) » English
 
 
English (auto-detected) » English
 
18409 Views
4 Likes
0 Comments
This is the tenth in a series that explains the thinking behind the Volere [1] requirements techniques—previous and future articles explore aspects of applying these techniques in your environment. This article illustrates how the requirements travel all the way through an organisation – and beyond - and how everyone is interested in/affected by them but all for different reasons.
16388 Views
13 Likes
4 Comments

You can now create an instant app from your schema, and add spreadsheet-like expressions for business logic – a complete system in minutes. In this article, we review a new technology from Espresso Logic that makes your requirements – schemas and logic - into working software, and show an example of building a full application from scratch.

25148 Views
24 Likes
4 Comments

Tracking project status means comparing where you really are at a particular time against the expectation of what “complete” means for this development cycle.  Monitor the status of just those functional requirements that were committed for the current release, because that’s the set that’s supposed to be 100 percent done before you declare success and ship the release.

28187 Views
23 Likes
0 Comments

How often has a customer asked you to write software that is user-friendly, robust, fast, or secure? No one will argue that those are worthy goals that everyone wants in their software products. However, they are terrible requirements. They give you no idea of just what “user-friendly” means, or how to tell if you’ve achieved the desired characteristics that mean “user-friendly” to a particular customer.

19828 Views
21 Likes
2 Comments

Do “Agile”projects need written requirements? Let us answer this question in this short article. As you may know, more and more software development teams have been adopting “Agile”processes over the past decade or so. As you may also know, Agile development processes such as Scrum and XP emphasize “working software” over requirements documentation.  Does this mean detailed, written requirements should be avoided in Agile projects?

31271 Views
35 Likes
1 Comments

In a new business analyst role, typically there will be a few types of requirements documents that are most commonly created...  In this article, I’ll go through 7 steps you can take to write better requirements documentation or learn how to write a new type of requirements document.

79173 Views
12 Likes
0 Comments

There are a myriad of requirements elicitation methods. The BABOK lists nine (Brainstorming, Document Analysis, Focus Groups, Interface Analysis, Interviews, Observation, Prototyping, Requirements Workshops, Survey/Questionnaire), but there are many more methods out there such as protocol analysis , job application design , and so on).

9718 Views
4 Likes
0 Comments

If you read the title and thought to yourself, “Hey, Mulvey got it wrong, it’s ‘Measure Twice, Cut Once’” I’ll bet you have had an experience with someone who used the old woodworking term. Woodworkers use it to indicate it’s better to double-check your measurements before you commit to cutting the wood, lest you waste time redoing work (and incurring expense if you have to buy more wood). It’s a great proverb to get you to think about double-checking your work and confirming your measurements. But what I’m talking about is using the measurement as an enterprise asset – once you create the measurement, use that over an over when you are working on different projects.

10500 Views
16 Likes
2 Comments

There’s little argument that investigating and identifying business needs (i.e. requirements) is a critical task of business analysis. However it’s of little use correctly identifying business needs if we can’t then effectively document them - to the clients who will be paying for the solution and to the developers who will be building it. In today’s time poor world we need to address both audiences in a single document.

13979 Views
13 Likes
2 Comments

Business analysts need to understand their role on a project. Please note I use the word 'role' and not 'job' or 'the work we do'. As business analysts, our role is to deliver business value. If you do not have a clear definition of what that business value is, how can you expect to deliver it? “Improve the customer experience.” Where is the business value in that? And how do you measure it? When faced with objectives that are poorly defined, the business analyst is allowed to become like that irritating toddler, constantly asking “why? why? why? why? why?”.

Page 3 of 8First   Previous   1  2  [3]  4  5  6  7  8  Next   Last   






Latest Articles

From an Intermediate to a Strategic Senior Business Analyst
Aug 09, 2020
0 Comments
It is strange how something that is supposed to be simple is actually so complex.  Something that is supposed to be a matter of linear career pro...





Copyright 2006-2020 by Modern Analyst Media LLC