Requirements Analysis (BABOK KA)

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.

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.

An alternative to eliciting use cases and user stories is to identify the external events to which the system must respond. An event is some change or activity that takes place in the user’s environment that stimulates a response from the software system. An event-response table (also called an event table or an event list) itemizes all such events and the behavior the system is expected to exhibit in reaction to each event.

The project sponsor decides to approve or not approve the BRD. But, this is only the position of yes or no. What were the criteria used to form that position? The Risk Tolerance Model helps form the position.

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.

No matter how thorough a job you do on requirements elicitation, there is no way to be certain that you have found them all. No little green light comes on to announce “You’re done!” You should always plan on new requirements trickling in throughout the project. However, an excessive rate of change of requirements suggests that important requirements were overlooked during elicitation.

How often do we hear “We don’t have time for analysis—let’s just get the project done!” Or “Modeling?! That’s so 1990s.” Or “Modeling is the developer’s job. Yours is to get the requirements.” Or “We’re doing Agile. Requirements evolve, so let’s not waste time with use cases or process models.” We have often heard every argument under the sun why spending time modeling requirements wastes time. However, we believe that modeling actually saves time.

Prior to the creation of something as potentially complex and ubiquitous of a website, an analyst must create a thorough, precise set of requirements in consultation with the right subject matter experts and business stakeholders. But unless one is armed with the proper planning procedures and techniques, the prospect of creating requirements for something as vast as an online business presence or functioning e-commerce system (or both) can be intimidating.

At the core of a good requirements management system is a good business process, not a fancy tool. Such process needs to clearly define how changes will be submitted and approved, and how team members will be notified when a change affects downstream or upstream work.

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.

As Business Analysts, we are involved in requirements development and management day in and day out with most of the time spent on eliciting, analyzing and specifying business and software requirements for multiple projects. We follow or adopt multiple frameworks, approaches and tools that help us to successfully gather and analyze requirements. Having done all these things to ensure the success of the projects, we still end up in a few projects wherein we have “missed” few requirements.

The CEO of a major corporation who was present when I described requirements traceability at a seminar asked, “Why wouldn’t you create a requirements traceability matrix for your strategic business systems?” That’s an excellent question. He clearly saw the value of having that kind of data available to the organization for each of its applications. If you agree with this executive's viewpoint, you might be wondering how to incorporate requirements traceability into your systems development activities in an effective and efficient way.

At long last, Business Analysts are stepping into the spotlight...  Most BAs, however, still rely on documents and spreadsheets to manually stitch together their requirements. For those BAs, this article points out five ways that documents and spreadsheets are hurting your career and preventing you from joining the growing number of BAs who are fully equipped for the future of the profession…
 

Multiple stages of a project can benefit from brainstorming, from identifying your stakeholders, to eliciting requirements, to enterprise analysis. In UML for the IT Business Analyst, Howard Podeswa describes brainstorming as useful “during the Initiation phase and whenever the project is ‘stuck’”.

Managers should do some soul-searching; do they really need that information or are they interfering with the responsibilities of others? My advice to managers is simple: Delegate responsibility, hold people accountable, and get out of their way.