SE351a: Software Project & Process Management. 11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa

Transcription

1 SE351a: Software Project & Process Management W4.1: Requirements Engineering 11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa SE351 Roadmap Introduction to Software Project Management Project Management Software Development Life Cycles Requirements Engineering Software Process & Project Metrics Software Project Planning Project Monitoring & Control Risk Management Software Quality Assurance 11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 2

2 The Objective is High quality Product Successful Development Process 11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 3 Software Project Management Machine Process SDLC PMLC 11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 4

3 PMLC Scope the Project State the problem or opportunity Establish the project goal Define the project objectives Identify the success criteria List assumptions, risks and obstacles Launch the Plan Recruit and organize project team Establish team operating rules Level project resources Schedule work packages Document work packages Project Close-Out Obtain client acceptance Install project deliverables Complete project documentation Complete post-implementation audit Issue final project report Develop Detailed Plans Identify project activities Estimate activity duration Determine resource Construct & analyze project network Prepare the project proposal Monitor & Control Progress Establish progress reporting system Install change control process Define problem escalation process Monitor progress versus plan Revise project plan 11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 5 SDLC Requirements/ Specifications Verify Software Requirements Specification Design Verify Design Document Implementation Test Software System Integration Test Operations Manual Operations Retirement 11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 6

4 Software Process: Example Requirements Engineering Process Requirements Elicitation Requirements Analysis and Negotiation Requirements Specification Requirements Validation & Verification Requirements Management Requirements 11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 7 Notes Readings Ian Sommerville, Software Engineering, 7 th Edition, 2005, Pearson Education Limited 11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 8

5 Outlines Fundamentals of Requirement Engineering Functional & Non-Functional Requirements Requirements Engineering Process Software Requirements Specification IEEE 830 SRS Standards Characteristics of Good SRS Document 11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 9 Requirements Engineering The process of finding, analyzing and documenting the services that the customer requires from a system, and the constraints under which it operates and is developed Requirements should specify what a system should do and not how it should do it the "what-versus-how" dilemma 11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 10

6 Examples The system shall allow users to search for an item by title, author, or ISBN The user interface shall be implemented using a World-Wide Web browser The system shall support at least 20 transactions per second The system facilities, available to public users, shall be demonstrable in 10 minutes or less 11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 11 Examples(Cont.) All functionalities of screens, buttons, menus, etc., in the user interface, and how they interact All data transformations, i.e., all computations need to be done by the system Throughput (transactions per unit of time) Capacity (amount of data, users, processes, etc. handled) Security (ability to resist intruders and protect privacy) Response times to user operations 11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 12

7 Why do Requirements Matter? Represent the first formalization of the desired deliverable Provide a basis for size and effort estimates Provide a firm foundation for initial design work 11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 13 Requirements vs. Cost Boehm and Papccio (1988) If it costs $1 to find and fix a requirement-based problem during the definitions, it can cost o o o o $5 during design $10 during coding $20 during unit test $200 at production Cost to Fix Error Req. Design Impl. Test Oper. Phase when Error Detected. 11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 14

8 Some Stat The later in the lifecycle an error is detected the more expensive to repair 54% of errors detected after coding and unit testing o 45% of these errors were and design errors Estimates indicate that 56% of all errors are those of the stage Requirements errors are typically non-clerical incorrect facts 49% omissions 31% inconsistencies 13% ambiguities 5% 11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 15 Requirements: Definition & Specification Requirements definition (User Requirements) A statement in natural language plus diagrams of the services the system provides and its operational constraints o Written for clients Requirements specification (System Requirements) A structured document setting out detailed descriptions of the system services o Written as a contract between client and contractor Software specification A detailed software description which can serve as a basis for a design or implementation o Written for developers 11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 16

9 Requirements Audience Requirements definition Client managers System end-users Client engineers Contractor managers System architects Requirements specification System end-users Client engineers System architects Software developers Software specification Client engineers (perhaps) System architects Software developers 11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 17 Problems with Natural Language Natural language relies on the specification readers and writers using the same words for the same concept A natural language specification is over-flexible and subject to different interpretation Requirements are not partitioned by language structures 11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 18

10 Natural Language Alternatives Structured natural language Graphical notations Mathematical specifications 11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 19 Functional Requirements using Structured Language A limited form of natural language may be used to express removes some form of ambiguity and flexibility imposes a degree of uniformity on a specification Often best supported using a forms-based approach 11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 20

11 Definitions and Specifications Requirements definition 1. The software must provide a means of representing and 1. accessing external files created by other tools. Requirements specification 1.1 The user should be provided with facilities to define the type of 1.2 external files. 1.2 Each external file type may have an associated tool which may be 1.2 applied to the file. 1.3 Each external file type may be represented as a specific icon on 1.2 the user s display. 1.4 Facilities should be provided for the icon representing an 1.2 external file type to be defined by the user. 1.5 When a user selects an icon representing an external file, the 1.2 effect of that selection is to apply the tool associated with the type of 1.2 the external file to the file represented by the selected icon. 11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 21 Form-based Functional Specifications Definition of the function or entity. Description of inputs and where they come from. Description of outputs and where they go to. Indication of other entities required. Pre and post conditions (if appropriate). 11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 22

12 Example of a Form-based based Functional Specification ECLIPSE/Workstation/Tools/DE/FS/3.5.1 Function Add node Description Adds a node to an existing design. The user selects the type of node, and its position. When added to the design, the node becomes the current selection. The user chooses the node position by moving the cursor to the area where the node is added. Inputs Node type, Node position, Design identifier. Source Node type and Node position are input by the user, Design identifier from the database. Outputs Design identifier. Destination The design database. The design is committed to the database on completion of the operation. Requires Design graph rooted at input design identifier. Pre-condition The design is open and displayed on the user's screen. Post-condition The design is unchanged apart from the addition of a node of the specified type at the given position. Side-effects None Definition: ECLIPSE/Workstation/Tools/DE/RD/ Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 23 The Requirements Document The document is the official statement of what is required of the system developers. Should include both a definition and a specification of. It is NOT a design document Again, it should set out WHAT the system should do NOT HOW it should do it 11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 24

13 The Requirements Document(Cont.) (Cont.) Requirements Analysis System Model System Model Requirements Document Requirements Definitions Definition of Requirements Requirements Specifications Specifications of Requirements 11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 25 Classes of Requirements Functional Requirements Non-functional Requirements Domain Requirements 11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 26

14 Functional Requirements Statements of services the system should provide o how the system should react to particular inputs o how the system should behave in particular situations Functional may be high-level statements of what the system should do but functional should describe the system services in detail 11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 27 Functional Requirements: Examples The user shall be able to search either all of the initial set of databases or select a subset from it The system shall provide appropriate viewers for the user to read documents in the document store Every order shall be allocated a unique identifier (ORDER_ID) which the user shall be able to copy to the account s permanent storage area 11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 28

15 Functional Requirements: Major Problems Imprecision Completeness & Consistency 11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 29 Functional Requirements: Imprecision Problems arise when are not precisely stated Ambiguous may be interpreted in different ways by different people The system shall provide appropriate viewers for the user to to read documents in in the document store the term appropriate viewers o User intention special purpose viewer for for each different document type o Developer interpretation provide a text viewer that shows the contents of of the document 11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 30

16 Functional Requirements: Completeness & Consistency In principle should be both Complete o Consistent o They should include descriptions of all facilities required There should be no conflicts or contradictions in the descriptions of the system facilities In In practice, it it is is almost impossible to to produce a complete and consistent document for large scale systems 11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 31 Non-functional Requirements Define system properties and constraints Properties: reliability, response time and storage, etc. Constraints: I/O device capability, system representations, etc. Non-functional may be more critical than functional, i.e., if these are not met, the system is useless 11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 32

17 Non-functional Classifications Product Specify the behavior of the delivered product o e.g., execution speed, reliability, etc. Organizational Related to the organizational policies and procedures o e.g., process standards used, implementation, etc. External Related to factors external to the system and its development process o e.g., interoperability, legislative, etc. 11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 33 Non-functional Requirements: Some Types Non-functional Product Organizational External Efficiency Reliability Portability Interoperability Ethical Usability Delivery Implementation Standards Legislative Performance Space Privacy Safety 11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 34

18 Non-functional: Major Problems Verifiability Measurements Interdependency 11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 35 Non-functional Requirement: Verifiability A Verifiable non-functional requirement A statement using some measure that can be objectively tested A system goal The system should be easy to use by experienced controllers and should be organized in in such a way that user errors are minimized A verifiable non-functional requirement Experienced controllers shall be able to use all the system functions after a total of two hours training After this training, the average number of errors made by experienced users shall not exceed two per day 11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 36

19 Non-functional Requirement: Measures --Examples Property Speed Size Ease of use Reliability Robustness Portability Measure Processed transactions/second User/Event response time Screen refresh time K Bytes Number of RAM chips Training time Number of help frames Mean time to failure Probability of unavailability Rate of failure occurrence Availability Time to restart after failure Percentage of events causing failure Probability of data corruption on failure Percentage of target dependent statements Number of target systems Non-functional Requirement: Interdependency Conflicts between different non-functional are common in complex systems e.g., to minimize storage space, the maximum store should not exceed 4Mbyte for handheld device, Portable programming language should be used however, using platform independent language may require more space Which is the most critical requirement? Which is the most critical requirement? 11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 38

20 Domain Requirements Constraints related to the application domain of the system and reflect its characteristics o Design constraints: o e.g., specific HW/SW or architectures, such as client-server o Implementation constraints: o e.g., implementing the product in C++ or using a specific GUI builder If domain are not satisfied, the system may be unworkable 11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 39 Domain Requirements: Example Library system domain There shall be a standard user interface to all databases which shall be based on the Z39.50 standard Because of copyright restrictions, some documents must be deleted immediately on arrival. Depending on the user s, these documents will either be printed locally on the system server for manually forwarding to the user or routed to a network printer 11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 40

21 Domain Requirements: Major Problems Understandability Requirements are expressed in the language of the application domain which is often not understood by software engineers Implicitness Domain specialists understand the area so well that they do not explicitly define the domain 11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 41 Classes of Requirements(Recap) Functional Requirements Non-functional Requirements Domain Requirements 11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 42

22 Requirements Engineering Process build a prototype The problem/ Opportunity elicitation develop Specification Review Management create analysis models 11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 43