VIEWS: 1 PAGES: 5 POSTED ON: 8/22/2011
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 . 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.
Pages to are hidden for
"Structuring complex requirements"Please download to view full document