Requirements Analysis (BABOK KA)

20285 Views
9 Likes
3 Comments

Many business analysts focus their full attention on tasks related to specifying, modeling, verifying, and validating requirements. And in doing so, they often forget about a critically important aspect of the BA work:requirements prioritization... Since good prioritizing skills help teams deliver business value faster, it’s a key competency for business analysts to develop. An effective to get better at prioritizing requirements is to follow this 3-step approach during the requirements discovery process.

19882 Views
5 Likes
1 Comments

This article discusses a tool for documenting, categorizing, ranking and decomposing various types of requirements (business/user and solution).  The business analyst (BA) can use this tool to capture high-level business and user requirements and then decompose them into solution requirements. In fact, the tool can be used multiple times and results strung together to provide forward and backward traceability of requirements through specification and test cases. 

25369 Views
17 Likes
5 Comments

Despite of all the extensive literature available on Requirements Analysis, it is hard to find one which proposes an established framework on how to use this tool in general sense of application. However, let’s try to map a generic algorithm that can be leveraged for suitable circumstances since every problem or situation is different from the other. We need to calibrate our analytic skills such that a general algorithm can be applied suitably depending on the situation(s).

23153 Views
46 Likes
0 Comments
This is a story of an outsourced product implementation contract between two companies, FinCo and ProdCo. What started out as an exciting contract turned out to be a bitter experience for both the companies. There are lessons to be learnt from this story – about outsourced contracts, about setting expectations and above all, about good old business requirements.
41515 Views
35 Likes
2 Comments
This article explores strategy mapping as discussed within Business Architecture Guild BIZBOK, and attempts to extend the discussion by defining a set of information and graphical principles that allows strategy to be represented graphically.
22924 Views
20 Likes
1 Comments
This article provides an in depth study on the concept of traceability, together with its implications and applications within a business context. Traceability is a term used in the IIBA BABOK, among other professional practices, in the context of requirements where requirements are said to be traced that provides alignment of requirements to each other. This implies that there are different classes or abstractions of requirements such as stakeholder, business and functional requirements. Traceability allows the alignment between all types or abstractions of requirements, telling a kind of story to how they all interrelate. 
15299 Views
1 Likes
1 Comments
This is the eleventh in a series that explains the thinking behind the Volere requirements techniques— previous and future articles explore aspects of applying these techniques in your environment.

This article focuses on the often-asked question: why, when I ask for requirements, do people give me solutions and what can I do to get the real requirement?
19833 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.

19409 Views
3 Likes
2 Comments
Solution Anthropology encompasses the work of anyone who works directly with the end users so the work is coordinated and consistent. Therefore Solution Anthropology is not one role, but a team of people with the responsibility to delight the end user and a broad skill set to accomplish just that.
22423 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.

39066 Views
41 Likes
4 Comments

People sometimes say that requirements are about “what” and design is about “how.” There are two problems with this simplistic demarcation.  This makes it sound as though there’s a sharp boundary between requirements and design. There’s not. In reality, the distinction between requirements and design is a fuzzy gray area, not a crisp black line. I prefer to say that requirements should emphasize “what” and design should emphasize “how.” 

20730 Views
29 Likes
0 Comments

Rather than expecting use cases to contain all of a system’s functionality, I prefer to employ use cases to help the business analyst discover the functional requirements. That is, the use cases become a tool to reveal functionality rather than being an end requirements deliverable themselves. Users can review the use cases to validate whether a system that implemented the use cases would meet their needs. The BA can study each use case and derive the functional requirements the developer must implement to realize the use case in software. I like to store those functional requirements in a software requirements specification, although you could add them to the use case description if you prefer.

22376 Views
14 Likes
0 Comments

It is certainly true that use cases are a powerful technique for discovering the functional requirements for a system being developed. However, this statement suggests that use cases are the only tool needed for representing a software system’s functionality. In most cases, they aren't.

77743 Views
46 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.
24726 Views
48 Likes
2 Comments

The structure that use cases provide is far superior to the nearly worthless technique of asking users “What do you want?” or “What are your requirements?” In this article I share my perspectives on when use cases work well, when they don’t, and what to do when use cases aren't a sufficient solution to the requirements problem.

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

 



 




Copyright 2006-2024 by Modern Analyst Media LLC