ACM SIGSOFT Software Engineering Notes Page 1 March 2007 Volume 32 Number 2
Structuring complex requirements
Abstract in a pre-defined format (we do not discuss which life cycle model
Sets of requirements that analysts are dealing with are often big the team will be following). The template for high-level
and complex. That makes requirements structuring one of the most requirements has sections like “functionality”, “data
important activities in requirements engineering, because of how requirements”, “security requirements”, etc:
requirements are structured and presented directly impacts the
requirements development process and the quality of requirements. HLRD
In this methodological paper we argue that a requirements analyst
business business data performance
has to build a requirements architecture that fits the properties of functionality reqs reqs ...
the problem. In particular, the requirements analyst should create a
clear vision of the principles governing how requirements are Req 1 Req 2
being defined, built and presented.
We review some of the instruments that an analyst can use to
structure requirements: requirements sets, views, levels and links. Detailed req 1 Detailed req 2
Among static views we emphasize concepts view, and also ...
consider functions view, application architecture view, and other
views; among dynamic views we consider use cases view,
operational scenarios view, events view, and others. We
specifically notice the importance of individual requirements sets,
The document with high-level requirements gets sign off from the
the purpose of which is to reveal the requirements for a particular
Line of Business. the standard process prescribes also to issue a
element (concept, function, action, etc.). We argue in favor of
detailed requirements document. How should the requirements for
differentiating between requirements model and requirements
that project be structured?
representation. We demonstrate on examples how requirements
architecture is needed in complex contexts.
The line of thought of the requirements analyst that has to deliver
requirements for this project may look like this:
• The standard process groups requirements by kind and
Sets of requirements that specify systems to be built are often big has just two levels for them. These levels correspond to
and complex. That makes requirements structuring one of the most the granularity of the vision of the problem and also to
important aspects of requirements development because efficiency the degree of readiness. Both kinds of structuring –
and quality of requirements gathering, analysis and other activities grouping by kind and using two levels – represent mainly
heavily depend on how requirements are structured and project management aspects. Therefore, the core of the
represented. requirements structure needs to be the high-level
We consider requirements for a given project as a set of sets that requirements document based on the template, as
will be read, queried and updated. First, using an example, we aim prescribed by the standard process, but other structures
to demonstrate that for structurally complex requirements sets it is (sets) of requirements are also necessary because of
necessary to define requirements architecture – in accordance with significant complexity and size of the system under
the properties of the problem. The ANSI/IEEE 1471-2000 construction (SuD). In particular, more than two levels of
standard defines architecture as "the fundamental organization of a requirements will be used where necessary.
system, embodied in its components, their relationships to each • Functionality will be presented by use cases.
other and the environment, and the principles governing its design • Dependencies between requirements will be shown with
and evolution”. In particular, that requires from requirements the help of simple links.
analysts having a clear vision of the principles that govern how
requirements are being defined, built and presented. Then we The requirements analyst also defines that it will be necessary to
consider the factors contributing to the complexity of requirements use several specialized views to reflect specific aspects of the SuD,
and review main constructs that can be used in requirements including:
architecture. • Features – to list main expectations so the agreement
about the future system can be achieved early in the
Case study development.
Suppose we have to build an online trading application that will • Concepts – to show the main concepts that the users of
enable clients from general public to buy / sell securities on stock the SuD will be using; to define the relationships between
markets. Suppose also that, though our application is new, it will concepts; to provide a framework for accumulating
use some functionality of an existing trading system that supports requirements related to a particular topic / component /
investment advisors. entity / …
The development team that will build the application uses a • Use cases – to define the functionality.
standard process that prescribes to deliver high-level requirements
ACM SIGSOFT Software Engineering Notes Page 2 March 2007 Volume 32 Number 2
• Functions – to be used in estimation and project planning. Figure 3. Screens view
This view will be derived from the use cases view. It is
useful as detailazation of the use cases view.
• Screens – to provide a logical overview of each screen. confirm
• Navigation – to represent non-trivial business rules for create_order
navigation between screens. It is useful because of large
number of expected screens.
• Application architecture – to delineate the existing system get_research
that will be used and the SuD; to help with defining the research_list
Diagrams representing these views (simplified) are provided
For example, the Create order screen may be defined with the
The diagram below shows the concepts of the problem domain and
indicates how the concepts relate to each other. Later this view
may serve as a basis for an object model. Each concept can have Figure 4. Create order screen
an individual requirements set associated with it that contains
requirements for this element (see also functions view below for security symbol security symbol find symbol
Figure 1. Concepts view here, on the screens view, we
have two buttons - buy and sell
quote get quote buy sell cancel - but in reality there is just one
requests quote from
is traded on Cancel destroys the current order, no
oversees has contains show_quote confirm data shall be retained
account security security symbol
Investment_advisor Client is represented by
requests creates issues
research company A functions view lists the functions that will be created. Note that
is about the set of functions does not coincide with the use cases set or with
the screens set, though they do use sometimes same concepts, such
as security symbol.
On the diagram below the functions view is combined with the
Use cases view individual view of the function create order.
A use cases view (a use case survey) provides a high-level picture
of the functionality delivered by the SuD: Figure 5. Functions view
Figure 2. Use case survey view create order
function create order
get quote parameters:
get research security symbol
log event "function is invoked"
A navigation view shows how screens are linked and also defines
Screens view the navigation rules. Having this view can save a lot of time in
A screens view consists of a list of the screens and screens case of large systems, where there are dozens and hundreds of
definitions that can be opened to investigate the details: screens with complicated rules of navigation between them.
ACM SIGSOFT Software Engineering Notes Page 3 March 2007 Volume 32 Number 2
the governing principles should be formulated as early as possible
Figure 6. Navigation view
for evident reasons: Requirements have to be consistent and
complete, easy to capture, analyze, modify, find and understand,
There shall be no access to
create_order screen if client did not seen in appropriate context and at appropriate level of details, not
sign all trading agreements duplicated; queries over requirements structure have to find all
sign_agreements occurrences of requirement; etc. Here experience, knowledge of
methodology and presence of tools and methodologies are hard to
Client get_quote show_quote Specific requirements sets
The views above are of a general kind and can be needed in nearly
any project. But every project will, of course, also require
problem-specific sets of requirements.
For example, the set of use cases from our case study above is too
big to be managed as one collection. Therefore, it will make sense
Application architecture view
The view below shows which components already exist and which to separate the use cases onto several sets / packages, such as
will be built for the SuD. Notice that the components below could “trading use cases”, “use cases that provide information about
be sets (packages) of use cases from the earlier views. However, in traded companies (research)”, etc.
a maintenance context that may be not always so. For more details Other sets of requirements will be needed to group together
and examples see . requirements related to a specific area of interest, such as
“scheduled events”, or “stock exchange quotes management
Figure 7. Application architecture view requirements”, etc.
IA research scope
Which sets of views are required for a project, depends on the
IA trading overall context.
IA quote For example, if we are building a 100% new system in a well-
account mgt IA DB
IA account mgt
Investment_advisor defined business domain, then probably the high-level application
research architecture view would not be required as a requirements view.
stock If the new system is built on top of an existing application, every
practitioner will tell you that considering the existing system
quote Trade_order_mgt exhange 2 architecture is unavoidable.
If we are building a system in a new business domain, the concept
view would probably be one of the centers of requirements.
A technical upgrade of an existing system may require, besides the
upgrade requirements themselves, only a use cases view or a
Other views functions view to support test planning.
Other views can be useful as well. For example, the following
business use cases view can be created to clarify the scope of the Context attributes
SuD: In many cases behind of what is called ‘requirements’ a multi-
level structure is lying. Ignoring this structure may lead to obscure
Figure 8. Business use cases view requirements, incompleteness, requirements bugs and lower
This business use case is out of scope (IA uses another
productivity. It is therefore a responsibility of the requirements
system to create a trade order) analyst to have a structure that suits best the needs of the current
project. These specific needs depend upon
business - the problem
- the product
request_trade - the project, and
- the life cycle model.
They translate into attributes of requirements complexity, such as:
• Number of business concepts (to implement, to deal with)
• Number of new concepts that the development team
needs to introduce
• Level of understanding of the problem
• Number of requirements
Governing principles • Number of levels of requirements
In our case study above the requirements analyst had to make • Number of kinds of relationships between requirements
many decisions about requirements views / sets required to • Etc.
represent the SuD. Note that this is not a “requirements waterfall”
in the sense that not all these decisions have to be made at one
point at the beginning of the requirements development. However,
ACM SIGSOFT Software Engineering Notes Page 4 March 2007 Volume 32 Number 2
see various contexts in which a requirement or a concept exists.
Types of views For example, the same concept ‘security symbol’ is present on
The list of views that a requirements analyst can use is rather big. both diagrams below:
Below we list most important views, organizing them in two
Figure 9. Create order screen
security symbol security symbol find symbol
Static views: Features view, concepts view, screens view,
functions view, application architecture view, reports view, etc. quantity quantity
Dynamic views: Business use cases view, use cases view,
get quote buy sell cancel
operational scenarios view, workflow view, screen navigation
view, events view, states view, etc.
Cancel destroys the current order, no
show_quote confirm data shall be retained
Indeed, there are many other views that can be useful or even
necessary in a specific project. Some of examples are views
defined in specific methodologies and frameworks, such as CMMI
framework (e.g. stakeholder needs view; stakeholder constraints
view; stakeholder interfaces views) or Zachman framework (e.g. Figure 10. Get quote screen
business logistics view; business schedule view; etc.).
security symbol find symbol
A separate class of requirements sets includes sets that reveal
details of a particular concept, function, component, etc. For get quote cancel
example, a requirements analyst may create a set to define the
concept ‘Client’. This individual set would contain requirements
that are specific to this concept and may contain other concepts, show_quote
e.g. ‘client name’, ‘client address’ (which also could have sets
with further details). An example of an individual set is given
above (Fig. 5, right rectangle).
While this example looks very simple post factum, identification
Links of such situations is one of non-trivial responsibilities of the
Another very important aspect of requirements architecture is links business analyst during requirements development.
between requirements and / or requirements sets. Links can
indicate dependencies between requirements, connect concepts Design
and their individual sets as described above, show precedence Just as in case with general software development, after
requirements for functions, specify, on a concepts view, how the requirements architecture is defined, quite a few of design
states of entities shall be coordinated, etc. Defining requirements decisions about requirements have to made, such as:
architecture, a requirements analyst has to make a number of links- • Which requirements attributes will be used
related decisions, such as: • Which naming conventions for requirements IDs will be
• The purpose of links between requirements and/or used
requirements sets • How traceability will be ensured
• Which link types will be used • Etc.
• Where links will be used
• How links will be represented Requirements presentation
• How links will be managed Requirements set is a model, and models can be presented in many
different ways. E.g. an object states view can be described using
For example, the analyst may decide that plain text or it can be presented with a diagram.
• Links will only be used for traceability between high-
level and detailed requirements
• There will be no links from features to high-level
• Links will also be used to show context dependencies
It may often happen that the same requirement / element is present
in several views. E.g. an actor may be present in the use cases
view and in the application architecture view; the concept
‘account’ will be used in several places. Therefore, views become
"threaded" – linked by the elements used in the views. Threading
exists whether we want it or not, but we can use threading to help
understand how views relate to each other. Threading also allows
ACM SIGSOFT Software Engineering Notes Page 5 March 2007 Volume 32 Number 2
Figure 11. Trade order states diagram
reviewed by IA
submitted reviewed created
submitted to market
discarded cancelled partially filled
if order expired
Here to each transition (represented by filled
link center) we can add descriptions
that define this transition
for example, we can show on
a transition, which use cases closed
Evidently, a textual description of the same logic would take much
more space and would be much less readable, understandable and
searchable. Notice, for example, the reference to the ‘approve’
action at the top right corner, which is easily identifiable because
of the selected way to represent the states. This is the action that
could be defined in the workflow view, so these two views become
threaded with this concept and as a result each one can be
This is a topic for a separate discussion. Our point here is that a
requirements analyst needs to choose consciously, which
representation fits his/her problem best.
Our goal was to demonstrate that an activity as complex as
requirements development demands thorough consideration of the
structure underlying the set of requirements for a given project.
Namely, a requirements analyst should make conscious decisions
about requirements architecture. This includes
• defining how requirements and requirements sets will
grouped and linked,
• choosing from many available views those views that
represent best the system,
• finding best representations for requirements sets.
Well-built requirements architecture helps avoid errors and
duplication, increases understanding, and improves the overall
quality and delivery time of requirements.
1. Diev, Sergey. Use cases modeling and software estimation:
Applying Use Case Points.
ACM SIGSOFT Software Engineering Notes. Volume 31,
Issue 6 (September 2006), 4 pages.