in the Cutter IT Journal (formerly American Programmer)
by Jim Highsmith, Nancy R Mead, Daniel J Mosley, Balasubramanian Ramesh, Lou Russell, Karl E Wiegers.
Introduction by Ed Yourdon.
48 pages, May 2000 (Vol 13, No. 5)
Subscription $485 annually (N. America), $585 (rest of World)
Publisher: Cutter Information Corp (www.cutter.com/consortium/ )
As Ed Yourdon says in his introduction, Requirements Engineering (RE) covers elicitation, analysis, specification, verification and management: a broad scope indeed. This issue of the Cutter IT Journal is devoted entirely to our subject; some earlier issues looked at requirements management tools and techniques.
Nancy R Mead of the SEI writes about Requirements Management and RE, arguing that 'You Can't Have One Without the Other'.
"One of my students once told me that her organization had established practices for requirements management so that they could "check off" the [SW-CMM] requirements management KPA, but they did not develop any software requirements!"
She is rightly scathing about attempts not much more sensible than this to drive a wedge between managing and engineering requirements. The new SW-CMM (version 2.0 Draft [6]) now includes three goals for Requirements Management, namely a repeatable process, an allocated requirements baseline, and consistency of software project plans, activities and work products with the allocated requirements. Hence "it is pretty clear" that the CMM mandates management activities that depend on already-established requirements. These only make sense if good RE practice is also followed.
Mead discusses, with examples, what happens when managers focus on meeting the CMM without regard to software engineering principles, or when engineers focus on the technically interesting parts of RE - such as elicitation techniques, or notations - without keeping track of changes. And she discusses the temptation
"..in industry, when a team goes into crunch mode. Good software engineering practices are often the first thing to go. A team may decide to 'fix up' the requirements at the end of a project, rather than trying to keep them current throughout. To the team, maintaining requirements seems like an overhead task."
This is sobering stuff, and excellent ammunition too, if you are faced with similar situations.
Karl E Wiegers, author of a textbook on Software Requirements, discusses key RE practices in an article entitled 'When Telepathy Won't Do'. He argues that
"Some highly exploratory or innovative projects can tolerate the extensive rework that results from informal requirements engineering. Most development efforts will benefit from a more deliberate and structured approach, though."
This is undoubtedly close to the truth for large and critical systems, but it runs against the grain of the current trend towards rapid development (as exemplified by Kent Beck's Extreme Programming, among other approaches). It depends on your audience and the scale of their applications.
Wiegers goes on to explain the traditional distinctions between business, user, and functional (system) requirements, before presenting his own view of the requirements development process and his taxonomy of RE. He then concentrates on key practices for the stages he identifies - elicitation, analysis, specification and verification. It is sensible and practical stuff, aimed at large projects in large organizations.
Balasubramanian Ramesh looks at Implementing Requirements Traceability. He explains in simple terms what this central and much misunderstood concept of RE actually means. To those of us who deal with traces every working day, it is hard to remember that the concept is less than obvious. Ramesh distinguishes low- and high-end users of traceability.
Low-end users
"use simple traceability schemes to model dependencies .. allocation .. and compliance. [They] do not capture process-related traceability information"
whereas high-end users
"employ much richer traceability schemes, thereby enabling more precise reasoning about traces"
Not surprisingly, the low-end users tend to sacrifice traces when a funding crunch comes along, whereas the high-end users think that "may prove to be a poor choice".
In other words, the cost/benefit argument about traces is much the same as that about writing requirements in general - it takes some sophistication to see the benefit and more to realize it on projects.
Ramesh points out that high-end users prefer to use tools that are embedded in their development environment, but that many requirements tools - he names DOORS as his example - address only limited aspects of the system development lifecycle. He goes on to argue that incompatibility among CASE tools is "particularly detrimental to the maintenance of a dynamic traceability practice, and points out the need for semantic (logical) links to be maintained across artifacts maintained by different tools. While agreeing with his intentions, I'd like to reply that platforms such as DOORS already provide for traceability across interfaces to a wide range of other tools; many of these interfaces are automatic, allowing developers to move seamlessly between specifications, design, and tests held in different tools. On the other hand, Ramesh's emphasis on traceability documents as 'living' entities seems entirely right.
Carol Dekkers and Maurizio Aguiar, in Double Duty Metrics, discuss how to use functional sizing to gauge requirements completeness.
Function Point Analysis (FPA) has traditionally been used to estimate software development cost. The authors argue here that the technique can equally be used to uncover requirements defects and omissions.
After pointing out that requirements "can single-handedly bring a software project to its knees" and the difficulty of judging whether a 600 page formal DoD SRS is complete, they argue that neither abstract frames of reference like structured analysis, nor informal personal experience are adequate to guarantee good results. Instead, they suggest, the formality of FPA offers a reliable route to quality. The function point approach identifies the required functions and the system scope, creates a data or entity-relationship model, counts the transactions and measures the complexity of user constraints.
Problems such as that an entity is defined but never used in a transaction, or is used but never defined, are highlighted during the process. Simple patterns such as 'AUDIO' - entities typically have Add, Update, Delete, Inquiry and Output operations - allow possibly missing operations in the specifications to be highlighted.
All this seems sensible and indeed highly beneficial as far as it goes. Where readers may feel doubtful is whether the rather traditional functions-and-dataflows approach is right for them. Not all systems are transactional, and much development is object-oriented; the applicability of FPA in such cases is uncertain. The claim that FPA is 'objective' is also disputable; all assignments of reality to a set functions are to some extent arbitrary.
Lou Russell, in Disaster Looks Good to Me, looks at the disaster waiting to happen when nontechnical project managers, to save time or face, approve requirements without validating them. Then she describes in plain and practical terms what to do.
The article provides good and useful 'checklists for success': a project scope, risks to be faced, constraints, business objectives, system (project) objectives, process needs, data/information needs, and validation. Each is properly documented in the article with an owner, reviewer, and 'Risk if skipped' - in other words, project managers, here is what will happen if you don't do this bit.
Russell manages to cover some very plain and straightforward pieces of advice in a fresh and readable style. She is obviously aiming primarily at the typical business data processing project, but her principles are more general than that. Highly recommended.
Daniel J Mosley discusses how to define test requirements for automated software testing. Perhaps one day it will be obvious to everybody that software should be tested against its requirements, or to put it the other way around, that requirements are incomplete if we can't see exactly how they are to be verified. But as yet it is not.
Mosley makes the obvious and correct points that to verify you must specify, and that the link between the two should be automated. However this seems to stem from a specification of test requirements, to be linked to test conditions; he doesn't discuss expressing the system requirements as scenarios/use cases, and then automatically generating test cases from those, which is a large task in test specification. He mentions favourably Rational Software Inc.'s products several times, and goes so far as to feel obliged to state in a side-note that he is not affiliated with them in any way!
The article ends by describing templates for test requirement specifications, and then illustrates in some detail what the test cases should look like, and argues that these should be automated and linked to the test requirements. These are good points but possibly somewhat obscured by his choice of terminology.
If this sort of publication helps the message of requirements engineering to reach a wider audience, especially of business executives, then it is very much to be welcomed. For busy senior managers, these few pages of concentrated knowledge may be the ideal introduction to the advantage that businesses can gain through proper handling of requirements.
Readers may also be interested to note that Cutter Information Corp. issues a free newsletter, the Cutter Edge (www.cutter.com/consortium), on IT issues affecting business.
© Ian Alexander, January 2001