Requirements Management and Communication (BABOK KA)

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.

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.

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.

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?

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.

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).

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.

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.

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?”.

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.

Many BAs are using the  BABOK which contains information about a Requirements Management process, from identifying organizational situations that give cause to a project, through to starting the requirements gathering process, to delivering a solution to the business or a client. TOGAF 9, from an Enterprise Architecture viewpoint, also provides some techniques to gather requirements to equally deliver business solutions. This paper illustrates the two processes, defines the mapping between the two approaches and identifies gaps in each.

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…
 

The most common way to represent the links between requirements and other system elements is in a requirements traceability matrix, also called a requirements trace matrix or a traceability table. When I’ve set up such matrices in the past, I made a copy of the baselined SRS and deleted everything except the labels for the functional requirements.

The purpose of this article is to assist business analysts in writing business requirements. This article provides six guidelines on technical writing. The six I cite here are the major ones I consider when writing a business requirements document (BRD).There are, of course,other technical writing guidelines; for comprehensive texts, see Further Reading (1). 

Simple requirements changes often have far-reaching impacts, necessitating that many parts of the product be modified. It’s hard to find all the system components that might be affected by a requirement modification. Assessing the impact of a proposed change is easier if you have a road map that shows where each requirement or business rule was implemented in the software.