SWEBOK Knowledge Area Jump-Start Document for Requirements Analysis Larry H. Reeker, U.S. National Institute of Standards and Technology

Transcription

1 Requirements Analysis 1 SWEBOK Knowledge Area Jump-Start Document for Requirements Analysis Larry H. Reeker, U.S. National Institute of Standards and Technology Purpose and Structure of this Document This document seeks to delineate the Requirements Analysis area of software engineering knowledge. It is intended to aid in the expansion of the area s description in the Stone Man version of the SWEBOK. As a first step in its development, an outline of the area was produced based on the sources mentioned under References below. These include all of the ones mentioned in the Procedure to be followed for the jumpstart document except that there was not a copy of Moore s book readily available, the references to standards are left for the next step. The references also include another book more specific to the Requirements area (see list below). The outline includes many references to locations of information used in making the outline. It was used in the next step, which was to classify the areas as seemed appropriate in terms of Vincenti s classification of engineering design knowledge (see discussion below). The items did not fit Vincenti s mode of classification on a one-to-one basis, but an indication of how they fit is indicated in parentheses after each item in the Vincenti tables. Having the dual perspective was an interesting exercise, resulting in some filtering and rethinking over two or three iterations, and should be helpful in deciding on the Stone Man arrangement of the knowledge. The Vincenti-type classification also emphasizes the dependence of Software Engineering on science, management, and mathematics principles. View of the Knowledge Area From the standpoint of the SWEBOK, the Requirements Analysis section involves all of the Software Engineering process as it is usually described, down to but not including Architectural Design (see Figure 1.9 on page 17 of [S]). In other words, all of the process of agreement between the SwE and the customer as to what is the purpose of the system to be produced, how it fits into the customer s business systems, and precisely (as precisely as possible without actually designing the system) what it will do. This involves a process of studying the domain of the proposed system; eliciting from the customer the requirements; analyzing those requirements from the standpoint of feasibility, cost, risks, and basic function; and producing a precise statement of these factors that can be discussed with the customer and agreed upon. This statement then serves as a guide in the design phase (determining how the requirements will be met), in the building and in the testing phase, and can be useful in later life cycle of the system. Determining requirements can involve considerations of the tradeoffs and decisions to be made in the architectural design phase, since these can affect the functional specifications, cost, and practicality of the system, but the decisions as to the architectural design are another matter, and are not part of this area. View of the Software Engineer s Position with Respect to this Knowledge Area The view taken here is that the software engineer is like the general practitioner in medicine, trained to have knowledge of a broad area that constitutes the core of software engineering (SwE). [Note: the abbreviation SwE is also used herein for software Engineer, but the meaning should be clear from context.] This recognizes that for myriad small software engineering projects, there is only one person involved. In a larger project, the SwE may work in cooperation with a Business Process Analyst, a SE (Systems Engineer), a SwSE (Software Systems Engineer), a HCIE (Human-Computer Interaction Engineer), a Software Project Manager, or a Systems Integration Specialist. But the SwE should be qualified to do a competent job in combining these roles for many projects without needing to call upon a specialist. (Thayer s article on Software Systems Engineering delineates the roles of a number of the types of specialists mentioned, and is worthwhile reading; see [T], p. 84ff.) Using Vincenti s Engineering Design Knowledge Categories in this Area The design of requirements does not fit smoothly into his categories at first sight, since they are designed to handle the entire design process for devices. The requirements themselves fit squarely into the Criteria and Specifications area, but many of the areas listed in the outline of the field can found in other categories.

2 Requirements Analysis 2 Vincenti describes Fundamental design concepts as the assumptions brought to the design process about the device in question. In other areas of engineering, the devices would be physical devices. However, the device being designed in requirements analysis for software engineering is an information system, with components being algorithms, programming languages, interfaces, etc. So the fundamental design concept material has been interpreted as the background material that allows the design of an information system and its components. (One could take a different view and consider the object of the design to be the requirements themselves, but this was tried, and the results were confusing. This way, the other aspects of requirements seem to fit fairly logically into the categories of knowledge as Vincenti defines them.) The Vincenti-type classification brings home the importance of the background knowledge for SwE from the requirements point of view. Of course, the background knowledge indicated is not particular to requirements within SwE. But it all comes into the requirement process, as even the programming language influences methods of specification of requirements, and maybe, as with O-O, the whole requirements process. As another example, the knowledge of some aspects of algorithm analysis influences choices made in the feasibility study and considerations of where human interaction should be used. References [These are common to the SWEBOK, except for [T], which specifically deals with the Requirements area.] M. and R. H. Thayer, Software Engineering. IEEE Computer Society Press, [D] S. L. Pfleeger, Software Engineering Theory and Practice. Prentice Hall, [Pf] R. S. Pressman, Software Engineering: A Practitioner s Approach (4 th edition). McGraw-Hill, [Pr] I. Sommerville, Software Engineering (5 th edition). Addison-Wesley, [S] W. G. Vincenti, What Engineers Know and How They Know It Analytical Studies form Aeronautical History. Baltimore and London: John Hopkins, [V] R. H. Thayer and M., Software Requirements Engineering (2 nd edition). IEEE Computer Soc. Press, [T] Articles cited from [T]: S. C. Bailin, Object-Oriented Requirements Analysis, pp M. Davis, A Comparison of Techniques for the Specification of Externals System Behavior, pp Davis et al, Identifying and Measuring Quality in a Software Requirements Specification, pp M., Requirements Engineering, pp7-22 *S. R. Faulk, Software Requirements: A Tutorial, pp *Fuggetta, A Classification of CASE Technology, pp J. A. Goguen and C. Linde, Techniques for Requirement Elicitation, pp H. Gomaa, The Impact of Prototyping on Software System Engineering, pp G. Kotonya and E. Sommerville, Requirements Engineering with Viewpoints, pp150- *J. D. Palmer, Traceability, pp J. Rumbaugh, Getting Started: Using Use Cases to Capture requirements, pp J. Siddiqi and M. Chandra Shekaran Requirements Engineering: The Emerging Wisdom, pp36-40 R. H. Thayer, Software Systems Engineering: An Engineering Process, pp D. R. Wallace and L. M. Ippolito, Verifying and Validating Software Requirements Specifications, pp * Faulk s paper is reprinted from [D]. Page numbers cited are from [T]; subtract 46 from them to get page numbers in [D]. This is also true for Fugetta; for them, add 119 to get page numbers in [D]. Also for Palmer (subtract 98 to get page numbers in [D]). For Fairley and, also in both books, page numbers are cited from [D].

3 Requirements Analysis 3 Requirements Analysis and Specification Outline of the Area with References (Citation format : Book, tag#<tag#>*. Books are S=Sommerville, Pf=Pfleeger, D= and Thayer, Pr=Pressman. Tags are s=section(s), p=page(s), c=chapter(s), and # is a number or range of numbers, and in the case of [D] and [T], individual paper first author included in brackets.) A. Domain Analysis and Requirements Capture (D p185 [Vienneau]; Pf s4.3, s4.8; Pr s11.1-2, 20.2,c20; S c4,5,6, p401; T p125[rumbaugh], 151[Kotonya]) [Domain Analysis is a study of relevant aspects of the enterprise in which the system is to be embedded and should always be conducted to assure that the SwE and the customer fully share an understanding of the proposed information system in context. However, despite the fact that difficulties originating in the lack of domain understanding are among the major problems in software development, domain anlaysis is often neglected. In the literature, it is most often mentioned in relation to defining a set of software products that can be used for multiple applications in a domain or for setting up objects that can be reused in multiple applications. Requirements collection, the activity in which the SwE seeks to pin down the requirements by examining documentation of existing systems and eliciting details from the customer and potential users, is subdivided into various topics. One of those areas, security, is neglected in most texts, but increasingly important for a variety of everyday applications.] 1. Domain study and modeling (Pf p479; Pr p279-80, s10.4, s20.2; S p80-81,401; T p125[rumbaugh]) 2. Requirement collection techniques (Pf s4.3,4.8; Pr p170, s5.3; S p84-98, T p110-22[goguen], p131-5[faulk]) 3. Determination of anticipated life cycle (D s1.3[budgen]; S p69; T p128-30[faulk]) 4. Special requirements (real-time, safety, security) (D p [gomaa]; Pf s1.10[and later : a running example], p378; Pr c15; S c210) 5. Human interface requirements (D p [remington], Pf p350; Pr s14.9; S c17) 6. Device (incl. sensor, communication) interface requirements (S p128-9, 298, 420) 7. Ranking requirements as essential, desirable, incidental (Pf p137, T p39 [Siddiqi]) B. System Requirements Analysis (D p44-54[fairley]; Pf c4; ; Pr s11.1-2; S c4-5; T [Faulk]) [System Requirements Analysis is the process by which the SwE delineates the data to be processed and the functional requirements expected of the system. These external system behaviors will be incorporated into a document, the Requirements Document (RD), which states, as precisely and completely as possible, what is expected. The RD forms a reference for the entire SwE process from the time it is approved by the customer. Since the way one analyzes a task and the way one expresses that task are very closely linked, requirements analysis and specification are closely linked, so references in the next section (C) overlap those in this section. Similarly, requirements analysis, as a process, proceeds in parallel with requirement collection, so some authors lump them together (e.g. Pressman).] 1. Feasibility study (Pr s , S p67) 2. Characterizing data to be processed (D p149f; Pf s4.2, p150-2,158-61; Pr s12.3; S c6) 3. Operational requirements (D p44-54[fairley]; Pf s4.2,p152-8;161-8; Pr s12.4; S 5.2,7.3) 4. Constraints posed by domain, including existing hardware and interfaces and legacy software and databases (S p35; s7.3) 5. Assessmant of alternatives, strategies and risks (D [Fairley]; Pf s3.4; Pr c6; S s1.3.1; T p39 [Siddiqi]) 6. Project cost/time and overall time estimates for system based on requirements (D p374-86[heemstra], Pf s3.3, Pr s5.5; S c29) C. Requirements Specification (D p44-54[fairley]; Pf s4.4; Pr s11.5-6; S s7.2; T p90[faulk]126-38, c4) [A variety of techniques are used in writing the RD, and they may contain mixtures of natural language and informal diagrams and various formalisms (diagrammatic or textual). The specifics chosen can depend to a

4 Requirements Analysis 4 certain extent on the type of domain and system being produced. They also can depend on the type of analysis technique used by the SwE (which may or may not depend on the domain and system). But their purpose is to delineate the components of the proposed system at a level of abstraction that allows an overview and also a clear understanding of what is to be produced. For an effective process and good software, they must be perspicuous to the customer, prospective users and all members of the implementation team, which is no easy task.] 1. Natural language-based specification the SRS (Pf s4.7; Pr s11.5; S, Ch7; T p136-8[faulk]) 2. Formal (or formalized diagram) specification techniques (D p19-20[]; Pf s4.4,4.5; S c9-11) a. Data-Oriented (Pr c12; S p101-2; T p275-85[reilly]) b. Behavior-Oriented (D p170-80[ashworth]; Pf p153-8; Pr s12.4; T p138-40[faulk]; [Davis],) c. Object-Oriented (D p [northrop], Pf p158-61; S p100,106-12; T p140-2[faulk]; [Bailin];) 3. CASE Tools (Pf p35,99; Pr s5.9, c29; S c25-27; T p350-64[fuggetta]) D. System Requirements Prototyping and Modeling (D 461-8[Carey]; Pf s4.6; Pr p32-3,s10.7-8,11.4,; S c6,8; T pp431-3[gomaa]) [Prototyping and modeling (including simulation) can be used as an aid in the requirements elicitation and analysis processes and in evaluation of requirements. Prototyping and modeling of the individual components and their interaction can also test the specifications and lead to their modification when the prototypes are shown to the customer. In some projects, a prototype with documentation and user manual have been substituted for at least some portion of the requirements documentation; but generally, it is better to get a requirements document earlier in the process unless the prototyping is extremely rapid ] E. Evaluating System Requirements (Pf s4.11, p145-6,439; Pr s4.2.1; S s ; T p164-75[davis], [Wallace]) [Throughout the process of eliciting, analyzing, specifying, and modeling the requirements, they are being subjected to an evaluative process. To a large extent, this evaluation helps to prevent costly fixes later in the software development process or errors that actually enter the delivered system. Some aspects of the evaluation can be formalized or singled out for particular study, and it is important for the SwE to be aware of their importance.] 1. Requirements validation (Pf s4.9; S p71; T p395[wallace]) 2. Evaluation of concept documentation (T p395[wallace]) 3. Traceability analysis (Pf p146,439,442; Pr p821; S p72,549; T p [palmer]) 4. Interface analysis (Pr p401-3; S s17.5; T p395[wallace]) 5. Initial planning for software system test (Pf p176, T p394[wallace]) 6. Verification (Pf p146, ; Pr p491; S p72,549; T 389ff[Wallace]) 7. Measurement (Pf s4.10; T p164-75[davis]) F. Requirements Management and Evolution (D s1.2[budgen]; Pf p181; Pr S s2.3.7,4.4; T p128-30[faulk]) [The management process for requirements can range from one that is largely bookkeeping, where a single SwE is involved and the problem is simple, to a highly complex one for a large project involving many people. It is part of the overall project management. Although requirements are often thought of as the initial development of a system, they should be retained and used later as the system needs to be evolved because of business process changes, external data format needs, changed hardware, etc. ]

5 Requirements Analysis 5 Requirements Analysis and Specification Classification Using Vincenti s Scheme Fundamental Design Concept Information System Characteristics (A-D) Hardware Characteristics (A-D) Data Structures, Programming Languages, Algorithms, Heuristics (A-D) Data Communication Methods & Protocols (A-D) Principles of Human-Computer Interaction (A-D) IS Project Design and Management (A-F) Background Knowledge Area (Computer Science/MIS Knowledge) (Computer Science/EE Knowledge) (Computer Science/Mathematics Knowledge) (Computer Science/EE Knowledge) (Computer Science/Psych Knowledge) (Management/Syst. or Ind. Engr. Knowledge) Criteria and Specifications Fit with Enterprise Domain (A.1) X X X X X Traceability of Requirements (E.3) X X X X Validation of Requirements (E.1) X X X X X Quality of Concept Documentation (C) X X X X X Anticipated Future Developments (A.3) X X X Human Interaction/Interfaces (A.5) X X X X Other Interface Requirements (A.6) X Requirements Maintainability (F) X X X X X Theoretical Tools Prototyping and Modeling (D) X X X X X System Life Cycle Assessment (A.3) X X X Feasibility Study, Strategy and Risk Assessment (B.1, B.5) X X X X Requirements Document (B/C) X X X X X Quantitative Data Cost Estimates (B.6) X X X X Effort Estimates (B.6) X X X Practical Considerations Development/Maintenance Costs (B.6) X X X X X Requirement Ranking and Tradeoff Analysis (A.4, A.7, B.5) X X X X X Safety Critical Aspects (A.4) X X X X Real Time Aspects (A.4) X X X X X Security Aspects (A.4) Legacy Constraints (B.4) X

6 Requirements Analysis 6 Design Instrumentalities Domain Analysis and Modeling (A.1) X X X X Requirement Elicitation Techniques (A.2) X X X X X Object Oriented Analysis/Specification (C.2.c) X X X X X Behavior-Oriented Analysis/Specification (C.2.b) X X X X X Data Modeling/Specification (C.2.a) X X X Prototyping (D) X X X X X CASE Tools (C.3) X X X X X