News Stay informed about the latest enterprise technology news and product updates.

Where do requirements models fit in the project lifecycle?

Modeling should not be considered something that's done only after requirements have been gathered. Use them throughout the requirements process to elicit and clarify requirements.

The following is an excerpt from "Requirements Models: The What, When, and Why," a research report produced by Info-Tech Research Group.

Modeling should not be looked at as something that is done only after requirements have been gathered. A use case model (see full report for links to notes on use cases) is created as part of the elicitation activity. Other models to analyze the requirements often result in questions and clarifications that change the requirements. Expect lots of concurrency in the work to gather and analyze requirements. This concurrency ensures that reviewers' comments are incorporated into the revised and final specification.

Benefits of requirements models?
A well-executed model has the following benefits:

  • Different perspectives reduce risk. Each type of model and its techniques consider the system from a different perspective. For example, a data model focuses on the data and data relationships while a process flowchart or swim-lane diagram often focuses on handoffs in the process. Each perspective is valid and necessary. The risk of missed requirements is reduced when the system is viewed with different lenses. Models help confirm that the requirements are complete and accurate.

  • Use of diagrams aids in communication. Text-only documentation can be hard to follow especially when trying to see the relationships between requirements or a sequence of events. Diagrams are a great way to augment text for clarity and verification of the information and requirements.

  • Provide a transition to design, build, and test. Many of the requirements models have partnering design models. For example:

    • The OOA models listed are part of a larger Object-Oriented Analysis and Design (OOAD) approach where there is a set of corresponding design models to drive work down to the next level.

    • Entity-Relationship models typically have two views. The logical view is for analysis, and the corresponding physical view is for building tables and takes into account changes that must be made to the logical view for data performance or other considerations.

    • Use Case models are frequently used to derive test sets and test cases.

  • Reduce maintenance costs. Requirements models can curb system maintenance costs by reducing the number of post-production change requests, fixes, and workarounds though having more complete, better understood requirements that have effectively transitioned into the built system.

>> Download the complete report.

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.