Whitepapers

A few notes, as a start for a white paper on requirements. In the field we are using at least two different approaches: Text and models. Lately a lot of attention is addressed to models, and how models help to validate requirements. Requirements written as text are around for decades. A question that comes up is: What are the advantages and disadvantages of the two approaches? Can they co-exist?  When you have additions, corrections, references to literature, etc. it will be are appreciated!

During the SAS Conferences, Morgantown, WV we spent time on modeling systems, as a valuable method to find defects in requirements and in a design of systems. So, at the start of a program development cycle, we have at least three methods at our disposal to find defects in requirements:
1)  a domain expert  reads documents, 
2)  we make models, ( using UML) and 
3)  a requirements analyst uses Requirements Assistant/RAWeb. ( and of course, all sorts of combinations!).

I assume that the intent of the development cycle is to create a system that meets the requirements. During the development we need to find (all) the defects, and find them as soon as possible. Time is indeed money!

My assumption is that the team that collected the requirements for the system to-be-developed has used a template like the Mil-Std-490, an IEEE template, or a Volere-requirements specification template, as a guide for a rigorous requirements specification.

Each of the three methods has some limitations in finding defects.  For instance: during the development cycle we have phases where nothing more than text is available, because a model still needs to be developed. 

Note: Question: Why would we develop a model? A reason could be that the requirements indicate a development that may not be feasible, and thus condidered as a high risk. Another reason could be that timing considerations are not well understood.

 And then the only methods available to find defects are 1) and 3). 

We usually build a functional or a control model. However, other aspects of the system (usually referred to as non-functional requirements) have defects in the requirements. To find these errors we need many more models than a functional model of the system.

Model

Advantages	Disadvantages
Express dynamic behavior	Difficult for domain experts to learn how to create
Easier to identify concurrency	Difficult to specify all non-functional requirements in a model (security, reliability, safety, etc.)
Able to show views at different levels of abstraction	Takes time to develop a model
See relationships between elements (traceability, dependencies, etc.)	Difficult for non-modeling person to understand requirements in a model
One step closer to development	How do you assess completeness?
Possible to execute models to identify problems
Useful in architecture driven process
Single source drives architecture, testing, development, etc.

 

Text

Advantages	Disadvantages
Easy to read the story	Translation required to move to modeling
Understood by everyone in the organization	Hard to find conflicting requirements
Able to express non-functional requirements	Difficult to specify dynamic behavior
Available for review sooner	Boring to review
Able to capture traceability with a Requirements Management tool	Difficult to review all requirements and relationships to each other

 

“Nonbehavioral requirements

Although use cases provide a good mechanism for describing system behavior and functionality, many nonbehavioral aspects associated with an event are not easily captured in the flow of events. Nonbehavioral requirements are not the functions or the behaviors themselves; they are attributes or characteristics of the system behaviors, such as security, reliability, and performance.”

Frank  Armour,  Granville Miller “Advanced use case modeling, page 185 (Addison-Wesley, 2001), see also page 150, 207, 209

References - Literature: