"The fundamental cause of the software crisis is that massive, software-intensive systems have become unmanageably complex. Furthermore, we cannot expect them to become any less complex, for as we improve our tools and gain experience in designing such systems, we actually open up more complex problem domains. As a solution to this crisis, we must therefore apply a disciplined artistry, using tools that help us manage this complexity."
-- Grady Booch

Practice Description
Managing complexity is key to lowering cost and schedule for large-scale development. System requirements define user needs and expectations. Requirements traceability links system requirements to derived requirements for hardware and software modules to help ensure that system requirements are implemented. Requirements traceability is essential for understanding the ripple effect of proposed changes to task output products, thus avoiding products becoming inconsistent when changes are made.

Practice Essentials

• Requirements traceability must begin with system requirements that unambiguously define user needs and expectations.
   
• System requirements should be defined by real end users following structured methods.
   
• System requirements should include scenarios (sequences of events) that could occur in operation.
   
• System requirements should specify system input that will cause the system to operate under highest stress.
   
• System requirements for information systems should include business rules. 
  • Business rules are very visible to the user.
     
• System requirements should include specification of all external systems to which there will be an electronic interface.
   
• Requirements must trace down from system requirements through all derived requirements and layers of design to the lowest-level software and hardware configuration items.
   
• Requirements must trace to different versions of the same CI.
   
• System requirements should explicitly specify requirements for open, public application programming interfaces (APIs) and data requirements for data interoperability.
   
• Design will not begin for any design layer until all requirements have been allocated and traced to that layer, including performance, reliability, safety, external interface, and security requirements.
   
• Each requirement for each software and hardware CI should be traced back to one or more system requirements to understand the impact of proposed changes to CI requirements.
   
• System requirements should be traced to individual test cases in a way that provides easy identification of the software CIs that are part of the implementation of the requirements tested by the test case. Requirements must be testable.
   
• If development will be done with incremental releases, a release build plan should be developed at project inception where all existing system requirements are traced into releases.
   
• If the incremental release model is to result in evolutionary definition of system requirements, whenever new system requirements are defined, they should be traced into future releases defined by the release build plan. 

Implementation Guidelines

• The program will define and implement a requirements management plan that addresses system, hardware, and software requirements. This plan will be linked to the SDP.
   
• All requirements will be documented, reviewed, and entered into a requirements management tool and put under CM. This requirements information will be kept current.
   
• The CM plan will describe the process for keeping requirements data internally consistent and consistent with other project data.
   
• Requirements traceability will be maintained through specification, design, code, and testing.
   
• Requirements will be visible to all project participants.
   
• Structured methods that are effective in helping end users define system requirements are:
   
  • User interface prototyping including screen navigation 
  • Data flow diagrams 
  • IDEFO diagrams 
  • Conceptual database design with entity/relationship diagrams
     
• If the application is to replace legacy software, it may be necessary to reverse engineer the legacy software code as part of system requirements definition.
   
• System requirements should be verified to be consistent.
   
• Requirements tracing should be done using an automated requirements traceability tool.
   
• Individual requirements should be linked to one or more critical requirements categories such as safety, security, and performance.
   
• All people on the project staff should have easy read-only access to the requirements traceability database.
   
• The automated requirements traceability database should allow easy access to the detailed definition of each requirement in the database.
   
• Requirements traceability should be implemented so that, whenever any requirement is changed, all parent and child requirements, software components, and test cases impacted by the change are identified.
   
• Evolutionary development should add new requirements, not change requirements implemented in delivered releases.
   
• Requirements volatility metrics should be computed from the requirements traceability database.
   
• The requirements traceability database should be under CM change control.
   
• A process must be in place that ensures statements of requirements in CM-controlled documents or automated tools other than the requirements traceability tool will always be the same as those in the CM-controlled traceability database. 

Things to Watch Out For

• People currently working in the domain of the system are seldom adequately involved in system requirements definition.
   
• System requirements usually do not include operational scenarios.
   
• System requirements usually do not include a specification of the external input that will result in the highest stress of the system.
   
• System requirements for information systems usually do not include business rules.
   
• Projects seldom verify consistency of system requirements in a formal, structured manner.
   
• Often requirements traceability is done only down to the computer software configuration item (CSCI) level instead of the code unit level as it should be.
   
• Often requirements traceability to test cases is not done.
   
• Often the requirements data in the traceability database is not under CM.
   
• Marketed "integration" of COTS requirements traceability tools with other CASE tools is usually data transfer, not integration. 

Figuring Out Where You Are - Project QuickLook

Chapter 6 contains a series of detailed questions that can be applied to any program to determine the health of its requirements management and traceability approach. These questions should be applied on a regular basis. However, there are some quick indicators that can be used to see if the requirements management and traceability process requires more in-depth examination. Specific "quicklook" questions are:

• Do you use an automated requirements traceability tool? If so, give the name and vendor of the tool if it is COTS, or describe the tool if it is not commercially available.
   
• Are system requirements traced to individual integration test cases?
   
• Are requirements linked in the requirements traceability database linked to requirements categories such as safety, security, and performance? If so, what are the categories to which requirements are linked? 

An inappropriate answer to any of these questions could indicate a more serious problem and merits further investigation.
 

Additional Considerations
 

An overall requirement on a successful project is the definition and maintenance of good processes. Process requirements definition starts at the system requirements.
 

• Management should demonstrate their commitment to software engineering practices by requiring via written policy an SEPG that coordinates development processes and improvement activities. This would include maintaining an organizational focus, periodic assessments of development processes, establishing a consistent process that can be tailored for each project, and proliferation of experiences, tools, and lessons between projects.  Management should reflect their commitment via their actions, focus, priorities, promotions, compensation plans and commitment of resources.  Management should ensure that improvement objectives support strategic objectives and guide improvement activities.  Management policy should also call for a standard software process, tailoring to each project, maintenance of process assets (tools, guides), and organized collection of project results to use in improving the standard process.
   
• An SEPG should be established and staffed by experienced professionals, with time to devote.  All software and systems engineering disciplines should be represented. The SEPG should develop an improvement plan that uses information from assessments, defines improvement activities/schedules, defines responsibilities, identifies resources, undergoes peer review/update and is agreed to by the organization's managers. Process improvement activities should be managed as a project, with corresponding discipline.  The objective for each activity should be clearly stated (experiment, adoption, etc). The SEPG should develop/improve the organization's standard development process and each project's tailored processes. Info on development processes & all team members should keep improvement activities in a database easily accessible.  Tools/processes that prove effective should be transferred to the organization in an organized manner IAW the plan. SEPG activities should be advertised & regularly seek feedback.
   
• The SEPG should develop and maintain the standard development process (or coordinate this activity) and all process assets.
   
• The organization's standard process is maintained according to a documented process which ensures that: the process satisfies all organizational policies, standards, etc. normally imposed by customers; state of the art tools and methods are used when appropriate; internal process interfaces are described; interfaces with systems engineering/contract management documentation support are identified; a process exists for proposing/reviewing/agreeing to/implementing process changes; the process undergoes per review and is placed under CM. The process is documented according to organizational standards and is decomposed into understandable segments, each process is well defined, and process inter-relationships are defined. 
  
  
• Approved software life cycle models are identified. The models must be compatible with the organization's systems approach and standard software processes, changes to the models are coordinated/approved/documented in an organized manner, the descriptions undergo peer review when introduced or changed, and the descriptions are under CM.
  
  
• Guidelines/criteria for tailoring the standard process are defined & maintained. The guidelines/criteria cover selecting and tailoring the life cycle, the process, and standards for documenting the project's process.  Tailoring criteria/guideline are placed under CM control and follow that process for review and update.  The SEPG approves the changes.
  
  
• A software process database is established and maintained.  The database collects and makes available information on software work products. Data entered is reviewed to ensure integrity.  The database is controlled/managed.  User access is controlled to ensure completeness, accuracy and integrity.  The data is available to all who need it, however.
  
  
• A process library is maintained.  Candidate documents are reviewed prior to inclusion.  Documents are catalogued for easy access. The library is kept current (revisions posted).  Contents are available to all organizational members/team members.  Use of documents is monitored to determine if document is still relevant.  The library contents are managed/controlled.

top

---