Software Engineering Body of Knowledge (v3) (2014) (811503), страница 11
Текст из файла (страница 11)
Maintaining an up-todate graph or traceability matrix is an activity thatmust be considered during the whole life cycleof a product. If the traceability information is notupdated as changes in the requirements continueto happen, the traceability information becomesunreliable for impact analysis.7.5. Measuring RequirementsAs a practical matter, it is typically useful to havesome concept of the “volume” of the requirements for a particular software product. Thisnumber is useful in evaluating the “size” of achange in requirements, in estimating the cost ofa development or maintenance task, or simply foruse as the denominator in other measurements.Functional size measurement (FSM) is a technique for evaluating the size of a body of functional requirements.Additional information on size measurementand standards will be found in the Software Engineering Process KA.8. Software Requirements ToolsTools for dealing with software requirements fallbroadly into two categories: tools for modelingand tools for managing requirements.Requirements management tools typically support a range of activities—including documentation, tracing, and change management—and havehad a significant impact on practice.
Indeed, tracing and change management are really only practicable if supported by a tool. Since requirementsmanagement is fundamental to good requirements practice, many organizations have investedin requirements management tools, althoughmany more manage their requirements in moread hoc and generally less satisfactory ways (e.g.,using spreadsheets).Software Requirements 1-15Wiegers 2003[2*]Sommerville 2011[1*]MATRIX OF TOPICS VS.
REFERENCE MATERIAL1. Software Requirements Fundamentals1.1. Definition of a Software Requirement1.2. Product and Process Requirements1.3. Functional and Nonfunctional Requirements1.4. Emergent Properties1.5. Quantifiable Requirements1.6. System Requirements and Software Requirements2. Requirements Processc4c4s1c4s1c10s1c10s4c1c1, c6c12c1c12.1. Process Models2.2. Process Actors2.3. Process Support and Management2.4. Process Quality and Improvement3. Requirements Elicitationc4s4c3c1, c2, c4, c6c3c22, c233.1. Requirements Sources3.2. Elicitation Techniques4. Requirements Analysisc4s5c4s5c5, c6,c9c64.1. Requirements Classification4.2. Conceptual Modeling4.3. Architectural Design and Requirements Allocation4.4. Requirements Negotiation4.5. Formal Analysis5. Requirements Specificationc4s1c4s5c10s4c4s5c12s5c12c11c17c7c4s2c4s2, c12s2,c12s3, c12s4,c12s5c4s3c10c4s6c4s6c4s6c4s6c15c13c15c155.1. System Definition Document5.2. System Requirements Specification5.3. Software Requirements Specification6. Requirements Validation6.1. Requirements Reviews6.2. Prototyping6.3. Model Validation6.4. Acceptance Testsc10c10Wiegers 2003[2*]Sommerville 2011[1*]1-16 SWEBOK® Guide V3.07. Practical Considerations7.1. Iterative Nature of the Requirements Process7.2. Change Management7.3. Requirements Attributes7.4. Requirements Tracing7.5. Measuring Requirements8. Software Requirements Toolsc4s4c4s7c4s1c4s6c3, c16c18, c19c12, c14c20c18c21Software Requirements 1-17FURTHER READINGSI.
Alexander and L. Beus-Dukic, DiscoveringRequirements [5].An easily digestible and practically orientedbook on software requirements, this is perhapsthe best of current textbooks on how the variouselements of software requirements fit together. Itis full of practical advice on (for example) howto identify the various system stakeholders andhow to evaluate alternative solutions. Its coverage is exemplary and serves as a useful referencefor key techniques such as use case modeling andrequirements prioritization.C. Potts, K. Takahashi, and A.
Antón, “InquiryBased Requirements Analysis” [6].This paper is an easily digested account of workthat has proven to be very influential in the development of requirements handling. It describeshow and why the elaboration of requirementscannot be a linear process by which the analystsimply transcribes and reformulates requirementselicited from the customer. The role of scenariosis described in a way that helps to define their usein discovering and describing requirements.A.
van Lamsweerde, RequirementsEngineering: From System Goals to UMLModels to Software Specifications [7].Serves as a good introduction to requirementsengineering but its unique value is as a referencebook for the KAOS goal-oriented requirementsmodelling language. Explains why goal modelling is useful and shows how it can integrate withmainstream modelling techniques using UML.O. Gotel and A. Finkelstein, “An Analysis of theRequirements Traceability Problem” [8].This paper is a classic reference work on a keyelement of requirements management. Based onempirical studies, it sets out the reasons for andthe barriers to the effective tracing of requirements.
It is essential reading for an understandingof why requirements tracing is an essential element of an effective software process.N. Maiden and C. Ncube, “Acquiring COTSSoftware Selection Requirements” [9].This paper is significant because it recognisesexplicitly that software products often integratethird-party components. It offers insights into theproblems of selecting off-the-shelf software tosatisfy requirements: there is usually a mismatch.This challenges some of the assumptions underpinning much of traditional requirements handling, which tends to assume custom software.1-18 SWEBOK® Guide V3.0REFERENCES[1*] I.
Sommerville, Software Engineering, 9thed., Addison-Wesley, 2011.[2*] K.E. Wiegers, Software Requirements, 2nded., Microsoft Press, 2003.[3] INCOSE, Systems Engineering Handbook:A Guide for System Life Cycle Processesand Activities, version 3.2.2, InternationalCouncil on Systems Engineering, 2012.[4] S. Friedenthal, A.
Moore, and R. Steiner, APractical Guide to SysML: The SystemsModeling Language, 2nd ed., MorganKaufmann, 2012.[5] I. Alexander and L. Beus-Deukic,Discovering Requirements: How to SpecifyProducts and Services, Wiley, 2009.[6] C. Potts, K. Takahashi, and A.I. Antón,“Inquiry-Based Requirements Analysis,”IEEE Software, vol. 11, no.
2, Mar. 1994,pp. 21–32.[7] A. van Lamsweerde, RequirementsEngineering: From System Goals to UMLModels to Software Specifications, Wiley,2009.[8] O. Gotel and C.W. Finkelstein, “An Analysisof the Requirements Traceability Problem,”Proc. 1st Int’l Conf. Requirements Eng.,IEEE, 1994.[9] N.A. Maiden and C. Ncube, “AcquiringCOTS Software Selection Requirements,”IEEE Software, vol. 15, no. 2, Mar.–Apr.1998, pp. 46–56.CHAPTER 2SOFTWARE DESIGNACRONYMSADLCBDCRCDFDERDIDLMVCOOPDLWe can also examine and evaluate alternativesolutions and tradeoffs.
Finally, we can use theresulting models to plan subsequent developmentactivities, such as system verification and validation, in addition to using them as inputs and as thestarting point of construction and testing.In a standard list of software life cycle processes, such as that in ISO/IEC/IEEE Std. 12207,Software Life Cycle Processes [2], software designconsists of two activities that fit between softwarerequirements analysis and software construction:Architecture DescriptionLanguageComponent-Based DesignClass Responsibility CollaboratorData Flow DiagramEntity Relationship DiagramInterface Description LanguageModel View ControllerObject-OrientedProgram Design Language• Software architectural design (sometimescalled high-level design): develops top-levelstructure and organization of the softwareand identifies the various components.• Software detailed design: specifies eachcomponent in sufficient detail to facilitate itsconstruction.INTRODUCTIONDesign is defined as both “the process of defining the architecture, components, interfaces, andother characteristics of a system or component”and “the result of [that] process” [1].
Viewed as aprocess, software design is the software engineering life cycle activity in which software requirements are analyzed in order to produce a description of the software’s internal structure that willserve as the basis for its construction. A softwaredesign (the result) describes the software architecture—that is, how software is decomposedand organized into components—and the interfaces between those components. It should alsodescribe the components at a level of detail thatenables their construction.Software design plays an important role indeveloping software: during software design,software engineers produce various modelsthat form a kind of blueprint of the solution tobe implemented.
We can analyze and evaluatethese models to determine whether or not theywill allow us to fulfill the various requirements.This Software Design knowledge area (KA)does not discuss every topic that includes theword “design.” In Tom DeMarco’s terminology[3], the topics discussed in this KA deal mainlywith D-design (decomposition design), the goalof which is to map software into componentpieces. However, because of its importance inthe field of software architecture, we will alsoaddress FP-design (family pattern design), thegoal of which is to establish exploitable commonalities in a family of software products. ThisKA does not address I-design (invention design),which is usually performed during the softwarerequirements process with the goal of conceptualizing and specifying software to satisfy discovered needs and requirements, since this topic isconsidered to be part of the requirements process(see the Software Requirements KA).This Software Design KA is related specifically to the Software Requirements, Software2-12-2 SWEBOK® Guide V3.0Figure 2.1.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
