Presentation is loading. Please wait.

Presentation is loading. Please wait.

CSDP Preparation Course Module II: Software Requirements.

Similar presentations

Presentation on theme: "CSDP Preparation Course Module II: Software Requirements."— Presentation transcript:

1 CSDP Preparation Course Module II: Software Requirements

2 Module II. Software Requirements2 Specifications The exam specific topics covered in this module are listed below, and are the basis for the outline of its’ content. A.Requirements Engineering Process B.Requirements Elicitation C.Requirements Analysis D.Software Requirements Specification E.Requirements Validation F.Requirements Management

3 Module II. Software Requirements3 Objectives After completing this module, you should be able to… To present an overview of software requirements engineering

4 Module II. Software Requirements4 Organization The organization of information for each specification topic is as follows: Topic Content Slides - detail the important issues concerning each topic and support the module objectives Topic Reference Slides - detail the sources for the topical content and provides additional references for review Topic Quiz Slides - allow students to prepare for the exam

5 Module II. Software Requirements5 Introduction What is Software? software -- Computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system. Contrast with hardware. [IE610] What is a Requirement? requirement -- (1) A condition or capability needed by a user to solve a problem or achieve an objective. (2) A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents. (3) A documented representation of a condition or capability as in (1) or (2). [IE610]

6 Module II. Software Requirements6 Introduction – 2 A Perspective These definitions imply concern for the user of the software as well as the developer. Wiegers emphasizes that the term users in such a definition should be generalized to stakeholders, because not all stakeholders are users. CAUTION: Don’t assume that all your project stakeholders share a common notion of what requirements are. Establish definitions up front so that you’re all talking about the same things. [KW03, p. 8]

7 Module II. Software Requirements7 Introduction – 3 Major Issues in Software Requirements The incorrect and incomplete software requirements specification The truncation of requirements activities over programming and testing The lack of cooperation by customers: To verify that the software requirements are correct To understood the structure and purpose of the software requirements specifications The problems associated with identifying which tool and/or methodology to use in developing and representing a software requirements specification [RT04, p. 4-9]

8 Module II. Software Requirements8 Introduction – 4 Fundamentals of Requirements In order to properly identify a requirement, we may apply the general property distinctions that the SWEEBOK Guide has identified [SW04, p. D-3]: Product and process requirements Functional and non-functional requirements Emergent properties Quantifiable requirements System requirements and software requirements

9 Module II. Software Requirements9 Introduction – 5 Product and Process Requirements - I Product parameter – a requirement on software to be developed Product requirement – Requirements which apply to the product of services to be developed Qualitative parameters – not directly measurable Functional – What it does External Interfaces – Data or command inputs or outputs Quantitative parameters – directly measurable Performance metrics – How fast, how much memory Quality metrics – Reliability, maintainability, security [RT04, p. 4-13]

10 Module II. Software Requirements10 Introduction – 6 Product and Process Requirements - II Process parameter – essentially a constraint on the development of the software (AKA process requirements) Process (Program) requirements – Applies to the activities associated with enabling the creation of a product or service Task – Perform and analyze, develop a product, operate a system Compliance evaluation – Measure compliance with a product parameter Regulatory/Standards – Compliance with laws, standards, regulations, and rules

11 Module II. Software Requirements11 Introduction - 7 Functional and Non-functional Requirements Functional requirements – describes functions software is to execute Example: formatting text Non-functional requirements – ones that act to constrain the software solution Further classes – performance, maintainability, safety, reliability, and others.

12 Module II. Software Requirements12 Introduction - 8 Emergent Properties Emergent properties – those which cannot be addressed by a single component, but system component interoperability Highly sensitive to the system architecture Sommerville provides three examples [IS01, p. 22]: Overall weight of the system Reliability of the system Usability of the system

13 Module II. Software Requirements13 Introduction – 9 Quantifiable Requirements Avoid vague and unverifiable requirements which depend for their interpretation on subjective judgment This is critical for non-functional requirements

14 Module II. Software Requirements14 Introduction – 10 System Requirements and Software Requirements System requirements - are for the system as a whole; sometimes referred to as user requirements Includes hardware, software, firmware, people, information, techniques, facilities, services, and other support elements Software requirements – derived from system requirements

15 Module II. Software Requirements15 Introduction – 11 Recognizing the Importance of Software Requirements Engineering [RT04, p. 4-7] Better quality in the software development process and the software product can be obtained if our methods and tools for gathering, modeling and analyzing user requirements are more effective, robust and codified in practice, i.e. an engineering approach Therefore, software requirements engineering (SRE) has emerged as an “engineering” approach to what used to be called requirements analysis and specifications

16 Module II. Software Requirements16 Introduction – 12 Role of Software Requirements in the Lifecycle [RT04, p. 4-17] Describes what the user wants or needs done Describes the final product, not methods and techniques for building the software Provides the basis for cost, schedule, and other resource estimates Primarily developed during the requirements phase of the lifecycle Can be developed in other phases of the lifecycle

17 Module II. Software Requirements17 Introduction Quiz 1. Which of the following requirement properties would be considered an emergent property of a software program? A.The fault detection system of the software B.The programming language of the system C.The reliability of the software D.The number of lines of code

18 Module II. Software Requirements18 Introduction Quiz – 2 2. Which of the following would most likely be considered a product requirement? A.The software shall be written in Ada. B.The student name shall be entered before the student grade. C.The system requirements for the software shall be formatted according to IEEE Std D.The software is built with company standards.

19 Module II. Software Requirements19 Introduction Quiz – 3 3. Which of the following is most true about a non-functional requirement? A.Describes functions software is to execute. B.Is highly sensitive to the system architecture. C.Is derived from hardware requirements. D.Acts to constrain the software solution.

20 Module II. Software Requirements20 Introduction References [IE610] IEEE Std , Standard Glossary of Software Engineering Terminology [IE1233] IEEE Std , Guide for Developing System Requirements [IS01] Sommerville, Ian, Software Engineering, 6 th Edition, Addison-Wesley, NY, 2001 [KW03] Weigers, Karl E., Software Requirements, 2 nd Edition, Microsoft Press, Redmond, WA, 2003 [RT04] Thayer, Richard, 2004 Certified Software Development Professional (CSDP) Preparation Course, Chapter 4: Software Requirements Engineering Concepts [SW04] SWEBOK – Guide to the Software Engineering Body of Knowledge: 2004 Version, IEEE Computer Society, Los Alamitos, CA, Chapter 2 – Software Requirements

21 Module II. Software Requirements21 A. Requirements Engineering Process A Process Defined process -- (1) A sequence of steps performed for a given purpose; for example, the software development process. (2) An executable unit managed by an operating system scheduler. (3) To perform operations on data. [IE610] Software requirements engineering (SRE) is a process, not a discrete activity

22 Module II. Software Requirements22 A. Requirements Engineering Process - 2 Software Requirements Engineering Process - I 1.Collect and categorize the various requirements (requirements elicitation) a.Identify relevant sources of requirements (usually the customers) b.Determine what information is needed (this will change as the requirements are developed) c.Collect the requirements from all parties

23 Module II. Software Requirements23 A. Requirements Engineering Process - 3 Software Requirements Engineering Process - II 2.Analyze the gathered information, looking for implications, inconsistencies, or unresolved issues (analysis) 3.Synthesize appropriate statements of the requirements (specifications) 4.Confirm your understanding of the requirements with the users (verification) 5.Plan and control the effort from beginning to end (management) [RT04, p. 4-20]

24 Module II. Software Requirements24 A. Requirements Engineering Process - 4 SRE Process Activities - I Software requirements elicitation – The process through which the customers (buyers and/or users) and developers (contractors) of a software system discover, review, articulate, and understand their requirements Software requirements analysis – Reasoning and analyzing the customers’ and users’ needs to arrive at a definition of software requirements

25 Module II. Software Requirements25 A. Requirements Engineering Process - 5 SRE Process Activities - II Software requirements specification – A document that clearly and precisely records each of the requirements of the software system Software requirements verification – The assurance that software requirements specifications are in compliance with the system requirements, conforms to document standards of the requirements phase, and is an adequate basis for the architectural (preliminary) design phase Software requirements management - Planning and controlling the requirements elicitation, analysis, and verification activities [RT04, p. 4-19]

26 Module II. Software Requirements26 A. Requirements Engineering Process - 6 Process Models Provide a basic outline of the requirements process Obtaining software requirements is not a discrete front-end activity Initiated at the beginning of the project, and is refined throughout the life cycle Software requirements are configuration items for management The process is adapted to the organization and the project Four major activities: elicitation, analysis, specification, and validation

27 Module II. Software Requirements27 A. Requirements Engineering Process - 7 Process Actors - I Those who participate in the process The requirements specialist mediates between domain of the stakeholder and software engineer Always include users (or operators) and customers (they may not be the same)

28 Module II. Software Requirements28 A. Requirements Engineering Process - 8 Process Actors - II Typical software stakeholders Users – Will operate software Customers – Commissioned the software Market analyst – Act as proxy customers Regulators – Authorities from application domains (EX: banking,) Software engineers – Have a stake in reusing components in successful products; must weigh their personal against the stake of the customer Must negotiate trade-offs with stakeholders to their satisfaction, within project constraints Stakeholders must be identified before this negotiation to occur [SW04, p. 2-3]

29 Module II. Software Requirements29 A. Requirements Engineering Process - 9 The Importance of Software Requirements These PeopleDepend on SW Req. to: Acquisition managementEstablish their needs Project management Determine tasks and schedule System engineersReq. allocated to SW TestersEstablish what is to be tested SW engineersEstablish top-level design Configuration controlEstablish req. baseline EveryoneGuide their effort - [RT04, p. 4-22]

30 Module II. Software Requirements30 A. Requirements Engineering Process - 10 Process Support and Management Linked to the four major process activities: elicitation, analysis, specification, and validation Concerned with issue of cost, human resources, training, and tools

31 Module II. Software Requirements31 A. Requirements Engineering Process - 11 Process Quality and Improvement Concerned with assessment of the process Measured by cost, schedule, and customer satisfaction Uses: Process improvement standards and models Requirements process measures and benchmarking Improvement planning and implementation

32 Module II. Software Requirements32 A. Requirements Engineering Process - 12 Other Issues in Software Requirements Engineering – I Requirements specifications often do not reflect the need and desires of the users and the customer Software requirements specifications are often incomplete and incorrect Users’ knowledge, experience, and cooperation greatly influence the quality of the specifications Developer’s knowledge of the customer domain greatly influence the quality of the specifications

33 Module II. Software Requirements33 A. Requirements Engineering Process – 13 Other Issues in Software Requirements Engineering – II Software requirements are constantly undergoing change Requirements sometimes specify the software design (a design constraint) Design is changed without a corresponding change in requirements [RT04, p. 4-22]

34 Module II. Software Requirements34 A. References [IE610] IEEE Std , Standard Glossary of Software Engineering Terminology [RT04] Thayer, Richard, 2004 Certified Software Development Professional (CSDP) Preparation Course, Chapter 4: Software Requirements Engineering Concepts [SW04] SWEBOK – Guide to the Software Engineering Body of Knowledge: 2004 Version, IEEE Computer Society, Los Alamitos, CA, Chapter 2 – Software Requirements

35 Module II. Software Requirements35 A. Quiz 1. According to the SWEBOK Guide, what are the four major activities of the requirements engineering process? A.Identification, specification, construction, and testing B.Elicitation, analysis, specification, and validation C.Analysis, planning, construction, and verification D.Elicitation, planning, construction, and testing

36 Module II. Software Requirements36 A. Quiz – 2 2. Which of the following property is least critical to the interaction between process actors and the requirements process? A.Process actor identification B.The nature of their ‘stake’ in the process C.The education of the actor D.The requirements they elicit

37 Module II. Software Requirements37 A. Quiz – 3 3. The requirements engineering process is: A.A discrete front-end activity of the software life cycle. B.Initiated at the beginning of a project and continues to be refined throughout the lifecycle. C.A continuous process that ends when requirements are specified and documented. D.The same for each organization and process.

38 Module II. Software Requirements38 A. Quiz – 4 4. Process quality and improvement relies most on which of the following? A.Product operator performance B.Human factors C.Requirements process measures D.Customer preferences

39 Module II. Software Requirements39 A. Quiz – 5 5. Product requirement validation occurs primarily after: A.Elicitation B.Analysis C.Specification D.Testing

40 Module II. Software Requirements40 B. Requirements Elicitation What is Requirements Elicitation? Concerned with where software requirements come from and how the software engineers can collect them. Stakeholders are identified and relationships established between the development team and the customer Also known as ‘requirements capture’, ‘requirements discovery’, and ‘requirements acquisition’ [SW04, p. 2-4]

41 Module II. Software Requirements41 B. Requirements Elicitation - 2 Major Issues Involving Requirements Elicitation - I It is not always clear who your customers or users are. Your customers/users cannot always state their requirements clearly or completely. Users don’t know what they want; they only know what they do. What they say they want may not be what they need or you may begin to define what you think they need, instead of what they want.

42 Module II. Software Requirements42 B. Requirements Elicitation - 3 Major Issues Involving Requirements Elicitation - II Their concept of the solution may not solve their problem. The customers or users will have expectations that may be unreasonable – or unknown to you. Not all of your customers or users talk to or agree with one another, so you must talk to all of them. Your customers or users may change. [RT04, p. 4-25]

43 Module II. Software Requirements43 B. Requirements Elicitation - 4 Requirements Sources - I From the SWEBOK Guide [SW04, p. 2-4] Goals – Sometimes called ‘business concern’ or ‘critical success factor’ Provides motivation for the software, but are often vaguely formulated Focus is to assess the value (relative priority) and cost of goals A feasibility study can do this at low cost Domain knowledge - The software engineer needs to be knowledgeable of the application domain Allows for assessment of that which is not articulated

44 Module II. Software Requirements44 B. Requirements Elicitation - 5 Requirements Sources - II Stakeholders – Also known as Process Actors The software engineer needs to identify, represent, and manage the ‘viewpoints’ of many different types of stakeholders The operational environment – The environment that software will be executed in will reveal system constraints and system element interoperability The organizational environment – May impose previously unidentified user processes

45 Module II. Software Requirements45 B. Requirements Elicitation - 6 Elicitation Techniques - I From SWEBOK Guide [SW04, p. 2-4] Once requirements sources have been identified, the software engineer can start eliciting requirements from them. Even if sources are cooperative and articulate, the relevant information must be captured. Some of these techniques are: Interviews – A traditional means of eliciting requirements

46 Module II. Software Requirements46 B. Requirements Elicitation - 7 Elicitation Techniques - II Scenarios – Provides a context for elicitation of user requirements Asks ‘what if’ and ‘how is this done’ questions The most common type of scenario is the use case Link to Conceptual Modeling because of scenario notations such as use cases and diagrams are common in modeling software Prototypes – Form paper mock-ups of screen designs to beta-test versions of software products Valuable tool for clarifying unclear requirements Overlap for use in requirements elicitation and requirements validation

47 Module II. Software Requirements47 B. Requirements Elicitation – 8 Elicitation Techniques - III Facilitated meetings – A group of people may bring more insight to achieve a summative effect to the requirements Conflicting requirements may surface earlier in this setting Beware of stakeholder politics Observation – Software engineers are immersed in the environment to observe the user interact between the software and other users Expensive to implement Helps reveal process subtleties and complexities

48 Module II. Software Requirements48 B. Requirements Elicitation – 9 ConOps - An Elicitation Tool - I Definition – concept of operations (ConOps) document – A user oriented document that describes a system’s operational characteristics from the end user’s viewpoint. [IE1362, Definition 3.4] It describes the user organization(s), mission(s), and organizational objectives from an integrated systems point of view. Applied to all types of software intensive systems: software- only or software/hardware/people systems

49 Module II. Software Requirements49 B. Requirements Elicitation – 10 ConOps - An Elicitation Tool - II Describes the user’s general system goals, missions, function, and components Helps bring the users’ views and expectations to the surface Provides an outlet for the users’ wishes and wants Helps the user feel in control May or may not be the responsibility of the acquisition manager [RT04, p. 4-29]

50 Module II. Software Requirements50 B. Requirements Elicitation – 11 The ConOps Document Style A ConOps document must be written in the user’s language using the user’s format A ConOps document should be written in narrative prose (in contrast to a technical requirements specification) ConOps should make use of visual forms (diagrams, illustrations, graphs, etc.) and storyboards wherever possible ConOps provides a bridge between the user needs and the developer’s technical requirements documents [RT04, p ]

51 Module II. Software Requirements51 B. Requirements Elicitation – 12 Elements of IEEE 1362 (ConOps) - I Clauses describe essential elements Provides information the writer wants the reader to know prior to reading the document Title and revision notice: Project name Version number of the document, Date of release, Approval signatures, A list of sub clauses that have been changed in the current version of the document

52 Module II. Software Requirements52 B. Requirements Elicitation – 13 Elements of IEEE 1362 (ConOps) - II Scope (Clause 1) Identification Document overview System overview Referenced documents (Clause 2) Current system or situation (Clause 3) Background, objectives, and scope Operational policies and constraints Description of the current system or situation Modes of operation for the current system or situation User classes and other involved personnel (Note)

53 Module II. Software Requirements53 B. Requirements Elicitation – 14 Elements of IEEE 1362 (ConOps) - III Justification for and nature of changes (Clause 4) Justification for changes Description of desired changes Priorities among changes Changes considered but not included Assumptions and constraints Concepts for the proposed system (Clause 5) Background, objectives and scope Operational policies and constraints Description of the proposed system Modes of operation User classes and other involved personnel (Note)

54 Module II. Software Requirements54 B. Requirements Elicitation – 15 Elements of IEEE 1362 (ConOps) - IV Operational scenarios (Clause 6) Summary of impacts (Clause 7) Operation impacts Organizational impacts Impacts during development Analysis of the proposed system (Clause 8) Summary of improvements Disadvantages and limitations Alternatives and trade-offs considered Notes (Clause 9) Appendices of the ConOps Glossary of the ConOps

55 Module II. Software Requirements55 B. References [IE1362] IEEE Std , Guide for Information Technology – System Design – Concept of Operations Document [JC04] Cleland-Huang, Jane, “Software Requirements,” in R.H. Thayer and M. Carstensen, Software Engineering, Vol. 1: The Development Process. IEEE Computer Society Press, Los Alamitos, CA 2004 [RT04] Thayer, Richard, 2004 Certified Software Development Professional (CSDP) Preparation Course, Chapter 4: Software Requirements Engineering Concepts [SW04] SWEBOK – Guide to the Software Engineering Body of Knowledge: 2004 Version, IEEE Computer Society, Los Alamitos, CA, Chapter 2 – Software Requirements

56 Module II. Software Requirements56 B. Quiz 1.As requirements are elicited, what source is most likely to impose previously unidentified user processes? A.The organizational environment B.The operational environment C.Stakeholders D.Application domain specialists

57 Module II. Software Requirements57 B. Quiz – 2 2. What is considered the traditional means or requirements elicitation? A.Observations B.Scenarios C.Interviews D.Prototypes

58 Module II. Software Requirements58 B. Quiz – 3 3. What is the most common type of scenario elicitation technique? A.The prototype B.The use case C.The facilitator meeting D.Observation

59 Module II. Software Requirements59 B. Quiz – 4 4. Which technique overlaps for use in requirements elicitation and requirements validation? A.Prototypes B.Facilitator meetings C.Interviews D.Observations

60 Module II. Software Requirements60 B. Quiz – 5 5. A concept of operations document (ConOps) should not be written A.In the user’s language using the user’s format B.Mostly in narrative prose C.With visual forms D.Primarily in the developers technical language

61 Module II. Software Requirements61 B. Quiz – 6 6. In the IEEE Std 1362 Concept of Operations (ConOps) Document, which of the following is fundamentally not included under the Concepts for the Proposed System (Clause 5)? A.Proposed design method of system B.Operational policies and constraints C.Description of the proposed system D.Modes of operation

62 Module II. Software Requirements62 B. Quiz – 7 7. In the IEEE Std 1362 Concept of Operations (ConOps) Document, which of the following is fundamentally not included in the document? A.Current system or situation B.Proposed design method of system C.Justification for the nature of the change D.Operational scenarios

63 Module II. Software Requirements63 C. Requirements Analysis Definitions software requirements analysis -- (1) The process of studying user needs to arrive at a definition of system, hardware, or software requirements. (2) The process of studying and refining system, hardware, or software requirements. [IE610] (3) Reasoning and analyzing the customers and users needs to arrive at a definition of software requirements. [RT02, p. 93]

64 Module II. Software Requirements64 C. Requirements Analysis – 2 First, Find Requirements Sources Systems requirements specifications Statements of work (SOW) and procurement specifications Customer prepared needs documents Concept of operations (ConOps) documents Observations and measurements of the current system Interviews with the customers and users Current system documentation Feasibility studies Models and prototypes [RT04, p. 4-33]

65 Module II. Software Requirements65 C. Requirements Analysis – 3 Software Requirements Analysis - I Software requirements analysis: The process of: Studying and refining system, hardware, or software requirements [IE610] Determining the feasibility of the requirements Detecting and resolving conflicts between requirements Discovering the system boundaries and its external interfaces Conducting trade-offs between requirement features Producing of the software requirements specification

66 Module II. Software Requirements66 C. Requirements Analysis – 4 Software Requirements Analysis - II Other activities during the requirement analysis phase: Determine the project management plan Determine the test plan and test specifications Determine draft user’s manual Determine the system interfaces [RT04, 4-32]

67 Module II. Software Requirements67 C. Requirements Analysis – 5 Distinct Processes of Requirements Analysis The SWEBOK has identified several distinct processes that occur during a successful requirements analysis Requirements classification (RC) –Helps to inform trade-offs Conceptual modeling (CM) –To understand the problem Architectural design and requirements allocation (AD & RA) –What parts will meet requirements Requirements negotiation (RN) –Establishes trade-offs

68 Module II. Software Requirements68 C. Requirements Analysis – 6 Requirements Classification - I Several dimensions: Whether it is functional or non-functional Whether it is derived from high-level requirement or is emergent Imposed by stakeholder or other source Whether it is on the product or the process

69 Module II. Software Requirements69 C. Requirements Analysis – 7 Requirements Classification - II The requirement priority: The higher, the more essential The requirement scope: A global requirement may affect architecture Volatility/stability: Identification for tolerant design Others are possible, and some may overlap

70 Module II. Software Requirements70 C. Requirements Analysis – 8 RC / Attributes - I Each Software Requirement Shall Have: Identifier: Every requirement must be assigned a unique identifier that allows it to be unambiguously referenced. Source: The source of the requirement may be (e.g.) a stakeholder from whom it was elicited or a higher-level requirement from which it was derived Date: When the requirement was formulated

71 Module II. Software Requirements71 C. Requirements Analysis – 9 RC / Attributes - II Each Software Requirement Shall Have: Rationale: The rationale explains the purpose of the requirement. This helps subsequent analysis, particularly if the requirement is challenged or needs to be reworked at a later stage. Type: This attribute records, for example, whether the requirement is functional or non-functional; whether it is a user interface requirement, a safety requirement, etc., or it is an original requirement or a derived requirement Priority: Each requirement need to be prioritized in relationship to other requirements, e.g., essential, conditional, optional (IEEE Std 830)

72 Module II. Software Requirements72 C. Requirements Analysis – 10 RC / Attributes - III Each Software Requirement Shall Have: Stability: Uncertainty surrounds a requirement should be recorded so that its likely volatility is made explicit and appropriate risk containment measures can be taken. Verification procedure: This attribute defines how to verify that the requirement has been satisfied once the software has been implemented. Status: The requirements status records its current position in the life-cycle of the requirement. [RT04, p. 4-43,44]

73 Module II. Software Requirements73 C. Requirements Analysis – 11 RC / Types of Software Requirements – I Functional requirements – A requirement that specifies a function that a system or system component must be capable of performing Performance requirements – A requirement that specifies a performance characteristic that a system or system component must posses For example, speed, accuracy, or frequency External interface requirements – A requirement that specifies a hardware, software, or database element with which a system component must interface, or that sets forth constraints on formats, timing or other factors caused by such an interface

74 Module II. Software Requirements74 C. Requirements Analysis – 12 RC / Types of Software Requirements – II Design constraints – A requirement that impacts or constrains the design of a software system or system component (sometimes called a negative requirement); For example, functional requirements, physical requirements, performance requirements, software development standards, software quality assurance standards Quality Attributes – A requirement that specifies the degree of an attribute that affects the quality the software must possess; For example: correctness, reliability, maintainability, or portability [RT04, 4-35]

75 Module II. Software Requirements75 C. Requirements Analysis – 13 RC / Examples of Design Constraints Execution speed – Use maximum of 50% of available cycle time (also called performance requirement) Language – Use Ada Maintenance – Meet available requirements of 0.98 (also called quality attribute) Human computer interface – Menus are require for system interface Memory utilization – Use maximum of 75% of available memory (also called performance requirements) Reliability – Meet reliability requirements of 0.99 (also called quality attributes) Security – Meet security requirements of 4 hours to break into the system (also called quality attributes)

76 Module II. Software Requirements76 C. Requirements Analysis – 14 RC / Examples of Quality Requirements Reliability – Probability that the software will perform its logical operation in the specified environment without failure Survivability – Probability that the software will continue to perform or support critical functions when a portion of the system is inoperable Maintainability - Average effort required to locate and fix a software failure User friendliness – The degree of ease of use or learning of a software system Securability – The probability that the software system can be made secure for a predetermined amount of time

77 Module II. Software Requirements77 C. Requirements Analysis – 15 Conceptual Modeling – I Their purpose is to aid in understanding the problem, not begin a design solution Types of models include data and control flows, state models, event traces, and others Factors that influence choice of model: The nature of the problem The expertise of the software engineer The process requirements of the customer The availability of methods and tools

78 Module II. Software Requirements78 C. Requirements Analysis – 16 Conceptual Modeling – II Useful to start with building model of the software context explains operational environment and identifies interfaces UML (Unified Modeling Language) is a widely used set of notations

79 Module II. Software Requirements79 C. Requirements Analysis – 17 CM / Structured Analysis (Yourdon) [RT04, p. 4-38]

80 Module II. Software Requirements80 C. Requirements Analysis – 18 CM / Real Time Structured Analysis (Ward & Miller) [RT04, p. 4-39]

81 Module II. Software Requirements81 C. Requirements Analysis – 19 CM / Object-Oriented Analysis (Object Diagram) [RT04, p. 4-40]

82 Module II. Software Requirements82 C. Requirements Analysis – 20 CM / Use Cases

83 Module II. Software Requirements83 C. Requirements Analysis - 21 Architectural Design and Requirements Allocation Point the requirements process overlaps with software or system design. Allocation is the assigning of responsibility to components for satisfying requirements. Permits detailed analysis of requirements Allows requirements to be broken down further IEEE Std is a Recommended Practice for Architectural Description of Software Intensive Systems

84 Module II. Software Requirements84 C. Requirements Analysis - 22 Requirements Negotiation Also known as ‘conflict resolution’ Conflicts between stakeholders arise from differences: Between incompatible features Between requirements and resources Between functional and non-functional requirements Unwise for software engineer to make unilateral decision Consultation leads to consensus trade-off Decision traceable back to the customer for contractual reasons

85 Module II. Software Requirements85 C. References [IE610] IEEE Std , Standard Glossary of Software Engineering Terminology [RT02] Thayer, Richard H., Software Engineering, Volume 1: The Development Process, 2 nd Edition, IEEE Computer Society, Los Alamitos, CA, 2002 [RT04] Thayer, Richard H., 2004 Certified Software Development Professional (CSDP) Preparation Course, Chapter 4: Software Requirements Engineering Concepts [SW04] SWEBOK – Guide to the Software Engineering Body of Knowledge: 2004 Version, IEEE Computer Society, Los Alamitos, CA, Chapter 2 – Software Requirements

86 Module II. Software Requirements86 C. Quiz 1.Which dimension of requirement classification is critical for consideration of tolerant design? A.Whether the requirement is functional or non-functional. B.Whether the requirement is on the product or process. C.Whether the requirement is volatile or stable. D.Whether the requirement is a high or low priority.

87 Module II. Software Requirements87 C. Quiz – 2 2. What is the most important attribute of a requirement? A.Identifier B.Source C.Verification procedure D.Priority

88 Module II. Software Requirements88 C. Quiz – 3 3. Which of the following is not a type of software requirement? A.Functionality B.Performance C.External Interface D.Complexity

89 Module II. Software Requirements89 C. Quiz – 4 4. What does allocation try to satisfy in the assigning of responsibility to components? A.Requirements B.Validation C.External interfaces D.Testing

90 Module II. Software Requirements90 C. Quiz – 5 5. What is a software engineer most likely to resolve by making a unilateral decision? A.Differences between incompatible features B.Differences between developer perception and developer reality C.Differences between requirements and resources D.Differences between functional and non-functional requirements

91 Module II. Software Requirements91 D. Software Requirements Specification Two Descriptions software requirements specification (software requirements) – 1. A document that specifies the requirements for a system or component. Typically included are functional requirements, performance requirements, interface requirements, design requirements, and development standards. [IE610] 2. A document that clearly and precisely records each of the requirements of the software system. [RT02, p. 143] In software engineering jargon, ‘software requirements specification’ typically refers to the production of a document, or its electronic equivalent, which can be systematically reviewed, evaluated, and approved. [SW04, p. 2-7]

92 Module II. Software Requirements92 D. Software Requirements Specification - 2 Role in Software Development Foundation for the software project Describes the system to be delivered Separates essential, desirable, and optional requirements Identifies which items are stable and which might be volatile States problems, not solutions States “what” not “how” [RT04, p. 4-47]

93 Module II. Software Requirements93 D. Software Requirements Specification - 3 In Context with Other Requirement Documents The System Definition Document – defines high-level system requirements System Requirements Specification – for system components Software Requirements Specification – for software components of the system

94 Module II. Software Requirements94 D. Software Requirements Specification – 4 The System Definition Document Sometimes known as the user requirements document or concept of operations document Records the system requirements Defines high level system requirements in language/terms understood by the system users or customers It may include conceptual models, usage scenarios, data, information, or workflows to illustrate the system concept [SW04, p. 2-7] The IEEE Std 1362 is a guide which describes the elements of a ConOps document

95 Module II. Software Requirements95 D. Software Requirements Specification – 5 IEEE The ConOps Document The IEEE Std 1362 is a guide which describes the elements of a ConOps document

96 Module II. Software Requirements96 D. Software Requirements Specification – 6 System Requirements Specification (SyRS) Software is always an element of a larger system EXAMPLES: Airplanes, the Space Shuttle, a cell phone Is a systems engineering activity System requirements are specified here, not software requirements Software requirements are derived from the system requirements The requirements for the software components of the system are then specified [SW04, p. 2-7] The IEEE Std 1233 is a guide for developing system requirements specifications

97 Module II. Software Requirements97 D. Software Requirements Specification – 7 IEEE Std 1233 (SyRS) Recommended practice for developing system requirements specifications

98 Module II. Software Requirements98 D. Software Requirements Specification – 8 Software Requirements Specification (SRS) - I Establishes understanding of the software product is to do, as well as what it is not expected to do Often accompanied by definition document for clarity Written in natural language Supplemented by formal or semi-formal description This allows for a more precise and concise description of software architecture Permits rigorous assessment of requirements before design Provides realistic basis for estimating product costs, risks, and schedules

99 Module II. Software Requirements99 D. Software Requirements Specification – 9 Software Requirements Specification (SRS) - II Choice of notation constrained by the documents’ writers Training, skills, preferences Quality indicators for SRS statements Imperatives, directives, weak phrases, opinions, and continuances Quality indicators for entire SRS Size, readability, specification, depth, and text structure The IEEE Std 830 is a guide for developing software requirements specifications

100 Module II. Software Requirements100 D. Software Requirements Specification – 10 IEEE Std 830 (SRS) Recommended practice for developing software requirements specifications (You should read this standard!) Lists Considerations for producing a good SRS Identifies The Parts of an SRS

101 Module II. Software Requirements101 D. Software Requirements Specification – 11 Considerations for Producing a Good SRS - I Nature of the SRS – The writer(s) shall address the following issues Functionality External interfaces Performance Attributes Design constraints imposed on an implementation The SRS writer(s) should avoid placing either design or project requirements in the SRS Environment of the SRS

102 Module II. Software Requirements102 D. Software Requirements Specification - 12 Considerations for Producing a Good SRS - II Environment of the SRS – The SRS writer(s) plays a specific role in the software development process Should correctly define all of the software requirements. Should not describe any design or implementation details. Should not impose additional constraints on the software. The SRS limits the range of valid designs, but does not specify any particular design

103 Module II. Software Requirements103 D. Software Requirements Specification - 13 Considerations for Producing a Good SRS - III Characteristics of a good SRS (I) – An SRS should be Correct – Only if every stated SRS is one the software shall meet Unambiguous – The particular context of the SRS is clear and there is only one interpretation Natural language pitfalls Requirements specification languages Representation tools Complete – Only if it addresses: All significant requirements Definition of the software response Identification of all references TBD’s are marked for resolution

104 Module II. Software Requirements104 D. Software Requirements Specification - 14 Considerations for Producing a Good SRS - IV Characteristics of a good SRS (continued - II) Consistent – With higher level documents; types of conflicts Specified characteristics of real-world objects Logical or temporal conflicts with two specified actions Redundancy Ranked for importance and/or stability – All of the software requirements are not equally important Degree of stability (expected changes to occur) Degree of necessity: Essential, Conditional, or Optional Verifiable – a requirement is verifiable if and only if there exists some finite cost-effective process with which a person or machine can check that the software product meets the requirement. Non-verifiable - Terms such as “good”, “well”, or “usually” are impossible to define

105 Module II. Software Requirements105 D. Software Requirements Specification - 15 Considerations for Producing a Good SRS - V Characteristics of a good SRS (continued – III) Modifiable – Requires that the SRS Has a coherent and easy-to-use organization Not be redundant Express each requirement separately (redundancy can lead to errors) Traceable – If the origin of each of its requirements is clear and it facilitates the referencing of each requirement in future development or enhancement documentation Backward traceability ( i.e., to previous stages of development) Forward traceability (i.e., to all documents spawned by the SRS)

106 Module II. Software Requirements106 D. Software Requirements Specification - 16 Considerations for Producing a Good SRS - VI Joint preparation of the SRS – Should begin with supplier and customer agreement on what completed software must do. Customers usually don’t understand software development well enough to write a usable SRS Software developers usually don’t understand customers well enough to specify requirements for a satisfactory system

107 Module II. Software Requirements107 D. Software Requirements Specification - 17 Considerations for Producing a Good SRS - VII SRS evolution – The SRS may need to evolve, as some details are impossible to obtain during the project’s initial phases. To handle this situation Specify as completely and thoroughly as possible; note incompleteness if it is known. Utilize a formal change process

108 Module II. Software Requirements108 D. Software Requirements Specification - 18 Considerations for Producing a Good SRS - VIII Prototyping – Should be used as a way to elicit software requirements More likely for customer to react to view than to reading Displays unanticipated aspects of system behavior SRS tends to undergo less change during development, thus shortening development time

109 Module II. Software Requirements109 D. Software Requirements Specification - 19 Considerations for Producing a Good SRS - IX Embedding design in the SRS – avoid it A requirement specifies an externally visible function or attribute A design describes a method to achieve that requirement Every requirement in the SRS limits design alternatives The SRS should not specify Partitioning of software into modules Allocating functions to the modules Describe the flow of information or control between modules Choose data structures

110 Module II. Software Requirements110 D. Software Requirements Specification – 20 Considerations for Producing a Good SRS - X Embedding project requirements in the SRS – The SRS should address the software product, not the process of producing the product. These following project requirements are reserved for other documents: Cost, delivery schedule, reporting procedures, software development methods, quality assurance, verification and validation, or acceptance procedures

111 Module II. Software Requirements111 D. Software Requirements Specification - 21 IEEE The Parts of an SRS - I Table of Contents 1.Introduction 1.Purpose 2.Scope 3.Definitions, Acronyms, and Abbreviations 4.References 5.Overview 2.Overall Description 1.Product Perspective 2.Product Functions 3.User Characteristics 4.Constraints 5.Assumptions and Dependencies 3.Specific Requirements Appendices Index

112 Module II. Software Requirements112 D. Software Requirements Specification – 22 IEEE The Parts of an SRS - II Functional Hierarchy [RT04, p. 4-51] 3.Specific requirements 1.External Interfaces 2.Functional requirements 1.Function 1 1.Introduction 2.Input 3.Process 4.Output 2.Function 2 3.… 4.Function n 3.Performance requirements 4.Design constraints 5.Quality attributes

113 Module II. Software Requirements113 D. Software Requirements Specification - 23 Writing a Requirement Suggested Method [RT04, p. 4-53] Requirement should be written as a single sentence, with a minimum number of conjunctions, and using modal verbs consistently i.e. shall, will, can, may. Example: Arm011: On completion of the arming sequence, there shall be a time delay equal to the escape period before the alarm enters the armed state This statement of requirements requires that the terms arming sequence, escape period, and armed state be defined in a glossary Use model verbs, e.g., use shall to indicate an essential requirement Arm011 is the requirement’s unique identifier

114 Module II. Software Requirements114 D. References [IE610] IEEE Std , Standard Glossary of Software Engineering Terminology [IE830] IEEE Std , Recommended Practice for Software Requirements Specification [IE1233] IEEE Std , Guide for Developing System Requirements [IE1362] IEEE Std , Guide for Information Technology – System Design – Concept of Operations Document [RT02] Thayer, Richard H., Software Engineering, Volume 1: The Development Process, 2 nd Edition, IEEE Computer Society, Los Alamitos, CA, 2002 [RT04] Thayer, Richard, 2004 Certified Software Development Professional (CSDP) Preparation Course, Chapter 4: Software Requirements Engineering Concepts

115 Module II. Software Requirements115 D. References – 2 [SW04] SWEBOK – Guide to the Software Engineering Body of Knowledge: 2004 Version, IEEE Computer Society, Los Alamitos, CA, Chapter 2 – Software Requirements

116 Module II. Software Requirements116 D. Quiz 1.Which document is used to derive the software requirements specification? A.The System Definition Document B.System Requirements Specification C.IEEE 1362 Concept of Operations D.IEEE 1016 Software Design Descriptions

117 Module II. Software Requirements117 D. Quiz – 2 2. What should the software requirements specification (SRS) writer avoid placing in the SRS environment of the SRS? A.External interfaces B.Performance or functionality C.Attributes or classification D.Either design or project requirements

118 Module II. Software Requirements118 D. Quiz – 3 3. Which of the following is not embedded design that would be written in the SRS? A.Partitioning of software into modules B.Specify logical requirements for the software C.Describe the flow of information or control between modules D.Choose data structures

119 Module II. Software Requirements119 D. Quiz – 4 4. Which of the following phrases most closely approaches verifiable language? A.“A good operability” B.“Well enough” C.“According to Standard X” D.“Usually acceptable”

120 Module II. Software Requirements120 D. Quiz – 5 5. Which of the following is not a good characteristic well written of a software requirements specification? A.Consistent B.Ranked C.Redundant D.Verifiable

121 Module II. Software Requirements121 E. Requirements Validation Defined Validation – 1. The process of evaluating a system or component during or at the end of the development process to determine whether it satisfies specified requirements. Contrast with verification. [IE610] 2. The process is a process for determining whether the requirements and the final, as-built system or software product fulfills its specific intended use [IEEE/EIA Std , Para 6.5] Validation (error = external customer requirements - product) Verification (error = internal specified requirements - product)

122 Module II. Software Requirements122 E. Requirements Validation – 2 Objectives of Verification and Validation To find errors in the software process and product as early as feasible To assist in determining good requirements and design To ensure that quality is built into the software and that the software will satisfy the software requirements To provide software management with insights into the state of the software project and product To satisfy users that the system is being developed according to standards and specifications To predict how well the interim products will result in a final product that will satisfy the software requirements [RT04, p. 4-58]

123 Module II. Software Requirements123 E. Requirements Validation – 3 Requirements Validation - I Requirements documents may be subject to validation and verification procedures Formal notation permits Software requirements validated to ensure that software engineer has understood the requirements Verify that a requirements document conforms to company standards that it is understandable, consistent, and complete

124 Module II. Software Requirements124 E. Requirements Validation – 4 Requirements Validation - II Different stakeholders should be able to review requirements documents Requirements documents subject to software configuration management as are other deliverables of software lifecycle processes Multiple points of validation in requirements process schedule Pick up problems before resources are committed Helps ensure requirements document defines the right software [SW04, p. 2-8]

125 Module II. Software Requirements125 E. Requirements Validation – 5 Subjects of Requirements Validation The SWEBOK has identified several knowledge areas of importance for the study of software requirements validation: Requirements reviews Prototyping Model validation Acceptance Testing

126 Module II. Software Requirements126 E. Requirements Validation – 6 RV / Requirements Reviews – I reviews -- A process or meeting during which a work product, or set of work products, is presented to project personnel, managers, users, customers, or other interested parties for comment or approval. Types include code reviews, design reviews, formal qualification reviews, and requirements reviews, test readiness reviews. [IE610]

127 Module II. Software Requirements127 E. Requirements Validation – 7 RV / Requirements Reviews – II Validation often done by inspection or reviews of requirements documents Reviewers look for errors, mistaken assumptions, lack of clarity, and deviation from standard practice Composition of reviewer group should include important stakeholders (customer for customer-driven project) Checklists are helpful

128 Module II. Software Requirements128 E. Requirements Validation – 8 RV / Requirements Reviews – III Can be done after completion of systems definition document systems specification document software requirements specification document the baseline specification for new release any other steps in the process IEEE Std 1028 provides guidance for reviews

129 Module II. Software Requirements129 E. Requirements Validation – 9 RV / Prototyping – I A means of validating the software engineer’s interpretation of the software requirements Also for eliciting new requirements Many different techniques Many different points in the process where prototype validation is appropriate

130 Module II. Software Requirements130 E. Requirements Validation – 10 RV / Prototyping – II Makes it easier to interpret the software engineer’ assumptions And give feedback when wrong Danger is distraction of resources from core functionality towards cosmetic issues Some suggestion prototypes that avoid software, such as flip-chart based mockups

131 Module II. Software Requirements131 E. Requirements Validation – 11 RV / Model Validation Validating the quality of models developed during analysis Example: In object models, perform static analysis to verify the communication paths exist between objects which exchange data If formal specification notation used, use formal reasoning to prove specification properties Validation (error = external customer requirements - product) Verification (error = internal specified requirements - product)

132 Module II. Software Requirements132 E. Requirements Validation – 12 RV / Acceptance Tests Essential property of software requirement is that it should be possible to verify that finished product satisfies it Requirements which cannot be validated are ‘wishes’ Must plan how to verify each requirement Validation requires quantitative expression Non-functional requirements difficult to validate

133 Module II. Software Requirements133 E. Requirements Validation – 13 Levels of Testing Versus Types of Errors Found Levels of TestTypes of Errors Found UnitCoding Integration Design System Requirements (Developer’s Interpretation) Acceptance Requirements (User’s Interpretation) “Errors made first are discovered last” [RT04, p. 4-56]

134 Module II. Software Requirements134 E. References [IE610] IEEE Std , Standard Glossary of Software Engineering Terminology [IE830] IEEE Std , Recommended Practice for Software Requirements Specification [IE1028] IEEE Std , Standard for Software Reviews [RT04] Thayer, Richard, 2004 Certified Software Development Professional (CSDP) Preparation Course, Chapter 4: Software Requirements Engineering Concepts [SW04] SWEBOK – Guide to the Software Engineering Body of Knowledge: 2004 Version, IEEE Computer Society, Los Alamitos, CA, Chapter 2 – Software Requirements [IE ] IEEE/EIA Std Standard for Information Technology, Software Life Cycle Processes – Implementation Considerations

135 Module II. Software Requirements135 E. Quiz 1.Software requirements validation should be viewed by whom and how often? A.Requirements analysts, often B.Stakeholders, often C.Customers, never D.Users, never

136 Module II. Software Requirements136 E. Quiz – 2 2. Requirements reviews: Can not be done before completion of the A.Systems definition document B.Systems specification document C.Software requirements specification document D.Baseline specification for new release

137 Module II. Software Requirements137 F. Requirements Management Defined software requirements management -- In system/software system engineering, the process of controlling the identification, allocation, and flowdown of requirements from the system level to the module or part level, including interfaces, verification, modifications, and status monitoring. [Thayer & Thayer Software Requirements 1997]

138 Module II. Software Requirements138 F. Requirements Management – 2 Observations The requirements process suggests a linear sequence (from elicitation through validation) A strict linear logic breaks down for complex system development Not every organization has a culture of documenting and managing requirements As products evolve: Need for feature changes demands review of original requirements Need to asses the impact of proposed changes Requirements documentation and change management key to successful requirements process [SW04, p. 2-9]

139 Module II. Software Requirements139 F. Requirements Management – 3 Two Type of Management Both of these Approaches Manage the Requirements Project management Planning the project Organizing the project Staffing the project Directing the project Controlling the project Technical management Problem definition Solution analysis Process planning Process control Product evaluation [RT04, p. 4-60]

140 Module II. Software Requirements140 F. Requirements Management – 4 Duties of the Software Project Manager - I The project manager is responsible for: Estimating the cost of the system based on the requirements Re-estimating the cost and schedule of the project when the requirements change

141 Module II. Software Requirements141 F. Requirements Management – 5 Duties of the Software Project Manager – II The technical manager is responsible for: Determining the adequacy of the requirements specifications Managing the requirements configuration of the system Controlling the volatility of the requirements and manage change history Perform requirements traceability Negotiating requirements changes between the acquirer (customer) and the developer The chief system engineer is frequently the technical manager [RT04, p. 4-61]

142 Module II. Software Requirements142 F. Requirements Management – 6 Key Requirements Tasks of the Project Manager Change control – Change control is the process of inhibiting unapproved changes to the software system Version control – Version control is the process of insuring the various versions of the software system is indeed that version Requirements tracing – Requirements tracing is the process of assuring that every requirement can be connected downward to the design module that implements it and upward to the system requirements that initiated it Status tracking – A system for maintaining information on the processing and implementation of the requirements [RT04, p. 4-62]

143 Module II. Software Requirements143 F. Requirements Management – 7 Subjects of Requirements Management The SWEBOK has identified several knowledge areas of importance for the study of software requirements management: Iterative nature of the Requirements Process Change Management Requirements Attributes Requirements Tracing

144 Module II. Software Requirements144 F. Requirements Management – 8 RM / Iterative Nature of Requirements Process - I Shorter development cycles, especially in competitive industries Often project is upgrade or revision of existing software Often requirements are never perfectly understood or perfectly verified Understanding that requirements continue to evolve as development proceeds

145 Module II. Software Requirements145 F. Requirements Ma1nagement – 9 RM / Iterative Nature of Requirements Process - II Risk of rework spans the whole software life cycle Change has to be managed through review and approval process Requirements tracing Impact analysis Software configuration management Configuration management (CM) -- In system/software engineering, a discipline applying technical and administrative direc­tion and surveillance to: identify and document the functional and physical characteristics of a configuration item, control changes to those characteristics, record and report change processing and implementation status, and verify compliance with specified requirements. [IE610]

146 Module II. Software Requirements146 F. Requirements Management – 10 RM / Change Management Procedures need to be in place and applied to proposed changes

147 Module II. Software Requirements147 F. Requirements Management – 11 RM / Requirements Attributes Requirements are not just composed of a specification, they should also include: Additional information to manage and interpret requirements The various classification dimensions of the requirement Verification method or acceptance test plan May also include additional information Summary rational of each requirement Source of each requirement and change history Most important requirement attribute: A unique and unambiguous identifier

148 Module II. Software Requirements148 F. Requirements Management – 12 RM / Requirements Tracing Concerned with: Recovering the source of requirements From software requirement back to system requirement it supports Predicting the effects of requirements From system requirement into software requirement and code modules that satisfy it Requirements tracing for a typical project form a complex directed acyclic graph (DAG) of requirements

149 Module II. Software Requirements149 F. Requirements Management – 13 RM / Measuring Requirements Concept of ‘volume’ of requirements for particular software product Useful in evaluating ‘size’ of change in requirements Useful in estimating cost of development or maintenance task A denominator in other measurements Technique: Functional Size Measurement (FSM)

150 Module II. Software Requirements150 F. Requirements Management – 14 Graphic, next slide: The Relative Cost to Correct A Software Requirements Error [RT02, p. 155]

151 Module II. Software Requirements151 F. Requirements Management – 15

152 Module II. Software Requirements152 F. References [IE610] IEEE Std , Standard Glossary of Software Engineering Terminology [RT02] Thayer, Richard H., Software Engineering, Volume 1: The Development Process, 2 nd Edition, IEEE Computer Society, Los Alamitos, CA, 2002 [RT04] Thayer, Richard, 2004 Certified Software Development Professional (CSDP) Preparation Course, Chapter 4: Software Requirements Engineering Concepts [SW04] SWEBOK – Guide to the Software Engineering Body of Knowledge: 2004 Version, IEEE Computer Society, Los Alamitos, CA, Chapter 2 – Software Requirements [Thayer & Thayer Software Requirements 1997] Reference unknown

153 Module II. Software Requirements153 F. Quiz 1.Which of the following is the technical manager not responsible for? A.Determining the adequacy of the requirements specifications. B.Controlling the volatility of the requirements and manage change history. C.Re-estimating the cost and schedule of the project when the requirements change. D.Negotiating requirements changes between the acquirer (customer) and the developer.

154 Module II. Software Requirements154 F. Quiz – 2 2. Due to the iterative nature of the requirements process, change has to be managed through the review and approval process. Which of the following is likely to require the least amount of management? A.Requirements tracing B.Impact analysis C.Software configuration management D.System definition

155 Module II. Software Requirements155 F. Quiz – 3 3. Requirements tracing is most likely concerned with the following: Recovering the source of requirements from: A.Software requirement back to the system requirement it supports B.Observation to elicitation technique C.Analysis into requirements specification document D.Software requirement to validation test

Download ppt "CSDP Preparation Course Module II: Software Requirements."

Similar presentations

Ads by Google