Requirements Analysis (BABOK KA)

17099 Views
16 Likes
0 Comments

As we travelled around India we were initially amazed at how the traffic flowed. India is a populous country, of course, and they have an ever-increasing number of vehicles.  No matter what time of day it was, the traffic seemed heavy. So, how can their constant flow of traffic work?
 

20511 Views
8 Likes
0 Comments

An effective business analyst doesn’t just “write requirements.” Instead, the BA should think about the most appropriate way to represent requirements-related information in a given situation. Besides the traditional default of writing natural language statements, the BA should determine when a picture or some other representation would be valuable.

21349 Views
21 Likes
2 Comments

If you create only one view of the requirements, you must believe it. You have no other choice. If you develop multiple views, though, you can compare them to look for disconnects that reveal errors and different interpretations. There’s an old saying, variously attributed to the Swedish Army, the Swiss Army, the Norwegian Boy Scouts, a Scottish prayer, and a Scandinavian proverb: “When the map and the terrain disagree, believe the terrain.”

39061 Views
12 Likes
2 Comments

Taking time to determine business requirements before launching into a new IT or process-based project is a critical component of good planning and protecting company assets. Clearly defining the current process, the problems that need to be focused on, and working with the people in the organization before beginning your project will allow for a much more streamlined process once you start, with better odds for success.

20184 Views
14 Likes
2 Comments

Ron Ross and Gladys Lam have written an important book for the business analyst community. It aims to get business analysts out of the technology ghetto that many of us get stuck in. Regardless of the type of analyst you are, I think it would be worth your time to get your hands on and read this book. I’ll explain why below.

31808 Views
33 Likes
6 Comments

There’s an old fable about six blind men who encountered an elephant for the first time. Although they couldn’t see it, they wanted to learn what an elephant was like. Each of them touched a different part of the elephant.

22870 Views
6 Likes
4 Comments

There are several situations in which recording only high-level requirements information increases the project’s risk. When you encounter situations such as the ones described in this article, expect to spend more time than average developing detailed requirements specifications.

22691 Views
3 Likes
2 Comments

Several conditions make it appropriate to leave the requirements descriptions at a higher level of abstraction. Recognize that these are broad guidelines. The BA should perform a risk-benefit analysis to balance the potential downside of omitting important information against the effort required to include it.

17906 Views
3 Likes
0 Comments

For several decades, software reuse has been a recognized solution to improving efficiency of software development. However, implementing reuse in practice remains challenging and the IT community has little visibility into the state of the practice specifically as it pertains to reusing software requirements. This paper presents the results of a survey conducted in the global IT industry in 2010 and discusses the state of the practice for software requirements reuse.

52819 Views
44 Likes
15 Comments

Recently I was chatting at a wine tasting event with a couple of lawyers, who I had just met. One was surprisingly inquisitive about my work in the software requirements arena. Apparently she was working on case involving software at that very time. At one point she asked me, “How do you know how detailed to make the requirements?”

20798 Views
20 Likes
1 Comments

Your new system just went live and the project, that replaced a critical legacy system, is coming to a close. Business analysts gathered requirements and worked closely with users and developers, but did you capture all of the requirements?

 

23261 Views
6 Likes
1 Comments

So you want to be a better requirements analyst. Or maybe you’re completely new to business analysis and you just want to learn what requirements analysis involves, period.

67068 Views
19 Likes
1 Comments

Requirements traceability ensures that each business need is tied to an actual requirement, and that each requirement is tied to a deliverable. This is a valuable practice for the business analyst. According to A Guide to the Business Analyst’s Body of Knowledge, (BABOK 2.0), all requirements are “related to other requirements, to solution components, and to other artifacts such as test cases. . . . The goal of tracing is to ensure that requirements (and ultimately, solution components) are linked back to a business objective.”

47794 Views
28 Likes
2 Comments

“Requirements are rules. They arise from business models, but they are different from those business models.”  Perhaps you’ve heard the argument. Maybe you’ve even made it yourself. Are they?  No!  Read this article to find out why.

15882 Views
2 Likes
1 Comments

In that article we presented our case that the typical approach to business requirements management was fundamentally flawed, with key issues being development of business requirements within a project context, and capture of those requirements using unstructured artifacts, particularly narrative.

Page 8 of 13First   Previous   3  4  5  6  7  [8]  9  10  11  12  Next   Last   

 



Upcoming Live Webinars

 




Copyright 2006-2024 by Modern Analyst Media LLC