Author: Michael Sayko

Building a software system by coding to requirements stored in a requirements management (RM) tool is not a new approach. Neither is using a software configuration management (SCM) tool to manage the source code files that comprise the software system under development. Modern RM and SCM tools facilitate software development because they manage changes to requirements and source code files that occur during the software development lifecycle.

Evolving requirements, like evolving source code, is a natural part of modern software development. Recognizing that requirements and source code evolve throughout the software development lifecycle, there is a need to track changes to both types of artifacts. Since changes to requirements often cause changes to an implementation, there is a desire to link requirements to the source code files that implement them. The realization of this need marked the emergence of requirements based development from a software configuration management perspective. The ability to manage requirements and source code in an integrated fashion is central to requirements based development. 

Why Should I Care About Requirements Based Development?

A working software system is characterized by one that meets its requirements. To develop the system, code must be written based on the requirements. Yet requirements are not static. Even when they are well specified at the start of a project, requirements evolve over time. Requirements evolve because even the most exacting customers do not know what they really want until they try to use the working software system. Once exposed to working software, customers develop a clearer picture of what they tried to envision when identifying requirements. Additionally, interfaces defined in documents, or in visual models, become clearer as they are implemented in the software system. For these reasons, the true requirements are not known until the software system is created.

Iterative software development, i.e., frequent deliveries of working software to customers, is probably the most effective way to identify the true requirements over time. The challenge for software project teams is to track changes to requirements to ensure that code developed, and code to be developed, meets the requirements. The premise behind requirements based development is that code is written to requirements, and code evolves as requirements change.

How Can I Implement Requirements Based Development?

To implement requirements based development from a software configuration management perspective, requirements need to be tied to source code files. The act of linking requirements to source code files ensures that

• each requirement is satisfied by one or more source code files,
• each source code file can be identified by the requirement(s) that it implements,
• every coding task is performed to satisfy a requirement, and
• changes to a requirement can flag the impacted source code file(s). 

Ideally, an integration between the RM tool and the SCM tool allows requirements to be linked to source code files. In reality, the level of integration varies among RM tools.

Earlier this year, MKS eliminated the need to couple two different tools by releasing a product that uses the same software architecture to manage requirements and to maintain source code files under version control. MKS Integrity Suite 2005  uses a single user interface and repository to manage requirements and source code files, and to maintain links between the two types of artifacts.

Clearly, there is an advantage to manage requirements and source code files in the same tool because an interface does not need to be configured and maintained between different tools. However, requirements based development is still possible when requirements and source code files are not managed within the same tool. Requirements based development can even be accomplished without an RM tool.

How Can I Implement Requirements Based Development Without an RM Tool?

When not using an RM tool, requirements based development can be implemented with a process enabled SCM tool.

Central to each process enabled SCM tool is a process model and workflow engine. The process model allows tool users to create process items to model (software development) activities that move through a workflow. These process items can be linked to source code files directly, or though change packages, to capture the source code files created as part of the activity.

By using process items, links can be maintained between requirements and the source code files that implement them. Each process item, or change package, typically corresponds to a development task. In turn, each development task relates to a requirement.

When practicing requirements based development, every development task is completed to satisfy a requirement. A software development team is not following requirements based development if a coding task cannot be tied to either a business or software architecture requirement.

Typically, there is a one-to-many relationship between requirements and development tasks. Ideally, each development task is fine grained so that it can be accomplished by one developer in no more than a few days. A development task that is larger in scope can be broken down into smaller tasks to fit this development model.

Incidentally, the approach of linking requirements to tasks to source code files is the underlying model used by MKS Integrity Suite 2005 The MKS requirements management model, which is maintained in a template in the tool’s repository, also makes use of features to model the functional realization of a requirement. Using this model, requirements are realized by features, that are worked as tasks, then implemented in source code files.

To implement requirements based development without an RM tool, the linkage between requirements and the tasks must be maintained by some other means. While tasks in the SCM tool can be named, or commented, to identify the requirement they implement, there needs to be a mechanism to link requirements to tasks. The reality is that at least some projects maintain this linkage in a spreadsheet. However, if requirements are stored in the same SCM repository as the source code files, it may be possible to create a process item to model the association between the requirement and source code file(s). In this case, the process item that models the association would be linked to both the requirement and source code file(s).

How Do I Capture Requirements?

To practice requirements based development, requirements are typically stored in a container. Since it was introduced by Ivar Jacobsen, the use case has become widely accepted as the artifact for documenting requirements. A Jacobsen style use case captures a requirement in the form of pairs of actor actions and system responses. The actor is external to the software system, and can be a person or another system. The action performed by the actor triggers a response from the system. Of course, the interaction between the actor and the system does not need to be through a GUI. The action by an external system can trigger a response by the software system.

Use cases can be stored in an RM tool in a format dictated by the tool. If an RM tool is not used, uses cases can be maintained under version control as text files or documents in the SCM tool. Keeping uses cases under version control in an SCM tool is certainly preferred to storing uses cases on a file system.

How Do I Manage Changes to Requirements?

Clearly, one of the most challenging aspects of requirements based development is managing changes to requirements. Managing changes means identifying the impact of a change. Since a change can occur at any point in the software development lifecycle, even after working code is delivered as part of an iteration, there must be a way to flag source code files that could be impacted by a change in a requirement.

Suspect links are a mechanism for flagging changes. A suspect link is a link between a requirement and a source code file that is flagged when a requirement changes. The flagging of the link alerts the software project team of the need to examine the source code file to determine if it is impacted by the requirement change. If the source code file is impacted, the software project team needs to schedule a new coding task to modify the source code file to reflect the changed requirement.

Conclusion

Coding to requirements is essential to create a working software system. However, this can be a challenge for most projects. Requirements, like source code files, are dynamic. The belief that requirements can be locked down prior to design is as antiquated as the waterfall model of software development. The reality is that a software development project must accept changing requirements. By practicing requirements based development with a process enabled SCM tool, the development team can manage changes to both source code files and requirements by maintaining links between the two types of artifacts.

Trackback(0)

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Write comment