Docstoc

Structuring complex requirements

Document Sample
Structuring complex requirements Powered By Docstoc
					ACM SIGSOFT Software Engineering Notes                         Page 1                  March 2007                 Volume 32 Number 2

                                        Structuring complex requirements
                                                              Sergey Diev
                                                             www.diev.com

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:
Introduction
                                                                           • 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
                                                                    get_quote
       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
       scope.
                                                                    show_quote
Diagrams representing these views (simplified) are provided
below.
Concepts view
                                                                 For example, the Create order screen may be defined with the
The diagram below shows the concepts of the problem domain and
                                                                 following diagram:
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

another example).
                                                                                                                     quantity       quantity
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
                                                                                                                                                                      function: create_order
   requests quote from
                                                        stock exchange

                                                                          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
                                          deals with
          requests          creates                                   issues
                                          trade order
                                                                                                          Functions view
                      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
                                                                                                                   find symbol
                                                                                                                   get quote                           parameters:

                                                                                                                   get research                                  security symbol
                        uc_create_trade_order
         Client                                                                                                                                                  quantity

                        uc_get_quote

                                                                                                                                                    log event "function is invoked"
                        uc_get_research



                         view_client_activiry
         IA

                                                                                                          Navigation view
                                                                                                          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
                                         create_order     confirm
                                                                                                      underestimate.
                        home
 Client                                  get_quote        show_quote                                  Specific requirements sets
                                                                                                      The views above are of a general kind and can be needed in nearly
                                         get_research     research_list
                                                                                                      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 [1].                                                                                 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
                                                                          client DB
 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
                                                                                          exhange 1
                                Client
                                                          trading
                                                                                                      practitioner will tell you that considering the existing system
                                                                                           stock
                                                          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
   Client                          Investment_advisor
                                                                              - 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
Requirements architecture
                                                                        • 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
groups:
                                                                        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
                                                                                 security symbol           find symbol
                                                                       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
        requirements
    • Links will also be used to show context dependencies
        between concepts

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
       disapproved

                                                                                             reviewed by IA

                       submitted             reviewed                     created

                                                                                                              approve
 in preparation

                                                                     submitted to market


                                             discarded   cancelled      partially filled

      Start


                                                                                           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
  initiate it




                                                                               End




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
understood better.
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.

Conclusions
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.

References
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.

				
DOCUMENT INFO