Skip to content

Business Requirments : What do all the models mean?

August 17, 2008

Requirements work is not finished as soon as requirements have been gathered. They must be organized, documented, analyzed, communicated, and managed throughout the project lifecycle. This ongoing requirements work impacts every project large or small. On very small projects these activities may be informal. As projects grow in size or complexity, more is needed to ensure common understanding. Modeling requirements helps with the organization, analysis, and communication activities.

What Types of Requirements Models Exist?

The three most frequent types of analysis each have their own sets of models and modeling techniques (see table below). Projects often combine analysis approaches and will use some cross-section of the modeling techniques. A number of techniques are applicable across the types of analysis.

Business Process Analysis:
•    All automated system requirements exist in the context of a business process. The models used here help define or refine the business process to ensure it s optimized.
•    Most medium to large-sized projects will involve business process analysis as part of determining the needs of the automated system supporting the process.
•    Often, projects will create both an “as-is” business process model and a “to be” business process model in order touide work on both automated and manual systems to support the process.

Business Process Models:
•    Business Use Cases
•    Swim-lane diagrams
•    Activity diagrams
•    Flowcharts
•    Workflow models (diagrams and text)

Object-Oriented Analysis (OOA):
•    Initially this was a very technical approach that evolved to include business analysis and not just systems analysis.
•    An approach that organizes business data and business behavior in-to classes that can be communi¬cated with and packaged into solutions.
•    Typically this involves using UML (Unified Modeling Language notations. UML has evolved to now include notations for business process modeling, business organization modeling, and business information modeling, creating significant overlap with business process analysis above.
•    Note that the Use Case model is one that has become widely used beyond the OOA paradigm – in part because it is easy to read and follow the diagram and text.
•    Use Case model (diagram and text)
•    Activity diagrams
•    Class/object model (diagram and text)
•    Sequence diagram

Structured Analysis:
•    The structured analysis approach focuses on breaking processes down further into their functional component parts and specifically how data flows within the process.
•    Unlike OOA process and data are analyzed and modeled independently.
•    Flowcharts
•    Data flow diagrams
•    Functional decomposition diagrams
•    Entity-Relationship model (diagram and text)

Where Do Requirements Models Fit in the Project Lifecycle?

Modeling should not be looked at as something that is done only after requirements have been gathered. A Use Case model (see sidebar for links to notes on Use Cases) is cre¬ated 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 concur¬rency 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

What Is a Requirements Model?

A requirements model is a representation, usually with both diagrams and text, of the problem or the solution.

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 infor-mation 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 analy sis, 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.
When Not to Model Requirements?
Not all situations require models. As indicated by the IIBA in their Body of Knowledge, models may not be required when:
•    The problem domain is well known.
•    The solution is relatively easy to construct.
•    Very few people need to collaborate to build or use the solution.
•    The solution will require minimal maintenance.
•    The scope of future requirements or needs is unlikely to grow substantially.

Any use of models and techniques requires that the standard notation and rules for that model/technique be followed. Some are easy to read and understand with very little training. Others are much more rigorous. A good guideline is to use notationally light
models/techniques as often as possible.

Bottom Line
Gathering requirements is a first step in any project. Using those requirements to drive the design and development of an automated system often calls for the use of requirements models. Understand what defines these models and when to use them.

Advertisements
No comments yet

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: