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

Transcription

1 SE351a: Software Project & Process Management W4.2: Requirements Engineering 13 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 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 2

2 Outlines Fundamentals of Requirement Engineering Functional & Non-Functional Requirements Requirements Engineering Process Software Requirements Specification IEEE 830 SRS Standards Characteristics of Good SRS Document 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 3 Requirements Engineering Process build a prototype The problem/ Opportunity requirements elicitation develop Specification Review Management create analysis models 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 4

3 Requirements Engineering Process Elicitation determining what the customer requires! Analysis & negotiation understanding the relationships among various customer requirements and shaping those relationships to achieve a successful result Specification building a tangible model of requirements System Modeling building a representation of requirements that can be assessed for correctness, completeness, and consistency Validation & Verification reviewing the model Management identify, control and track requirements and the changes that will be made to them 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 5 Requirements Engineering Process(Roadmap) Process Requirements Elicitation Requirements Analysis and Negotiation Requirements Specification Requirements Validation & Verification Requirements Management 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 6

4 Requirements Elicitation Requirements elicitation is the activity during which software requirements are o discovered, articulated, and revealed from stakeholders o or derived from business/system requirements Sources may be business/system requirements documentation customers end-users domain specialists or market analysis 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 7 General Requirements Elicitation Process A general requirements process would be: 1) Identify all stakeholders who could be sources of requirements: o Users o Clients o Domain experts o DBAs, QAs, Programmers, etc. 2) Ask relevant questions to gain an understanding of the problem, issues and constraints 3) Analyze the information looking for conflicts, ambiguities, inconsistencies, problems or unresolved issues 4) Confirm your understanding of the requirements with the stakeholders 5) Create requirements statements 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 8

5 Requirements Elicitation: Problems Users Side Users may know what they want but are unable to articulate the requirements Users may not know what is technologically capable and may not consider what is possible Users and developers sometimes don't speak the same language No single user has all the answers, the requirements will most likely come from many sources 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 9 Requirements Elicitation: Problems Developers Side Developers may not have the necessary skills to get the requirements from the users Developers may be unable to develop a rapport or understanding of the users needs Developers sometimes don't appreciate the needs or concerns of the users Developers sometimes tend to bulldoze the users into agreeing on the developers requirements 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 10

6 User Involvement It is important that all stakeholders are involved, particularly important that the user be involved o usually, the users know what the system should do and have the domain expertise However, users also have problems articulating their needs! 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 11 Ways to get the User Involved Several methodologies/techniques to involve users Generally, 3 main styles 1. Consultative Design 2. Representative Design 3. Consensus Design 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 12

7 User Involvement Consultative Design Users are sources of information with little or no influence Decision making power is in the hands of the developers Techniques in this style are: Interviewing Structured meetings Steering committees Brainstorming 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 13 User Involvement: Representative Design User representatives are involved in the design formulation decision making Some techniques of this style are: Joint Application Design (JAD) through facilitated meetings attempts to have more user involvement in the development process Quality Functional Deployment (QFD) quality management technique that helps to understand the relative importance of solution elements to the customer 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 14

8 JAD: Participants Executive Sponsor: Attends opening and closing session Facilitator: Session leader, Mediator, resolve group conflicts Team: Users, Managers, Developers Scribe: Records meeting details, Action items, Publishes meeting proceedings Observer: Development team, Interested parties, Not active participants, Silent audience 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 15 JAD: Phases It evolves from a definite start to a clear finish 1. Project Definition It involves defining project purpose, scope, and objectives, identifying JAD team members, setting schedules, etc. 2. Research It involves gathering more details about the user requirements, exploring problem domain, etc. Then, the Session agenda is prepared listing what needs to be decided in the session. 3. Preparation It involves preparing everything needed for the session, such as visual aids, working document, flip charts, overhead transparencies 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 16

9 JAD: Phases 4. The Session This is the actual workshop session. JAD team members define business process, project requirements, etc. Agreed-upon decisions are documented as scribed notes and forms 5. The Final Document The scribed information from the session put into JAD document with signed approval form 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 17 How to Run Good JAD Meetings? Facilitation Good leader to manage the meetings Agenda setting and structure Must have meeting objectives Plan of action Documentation Scribe meeting details Group Dynamics Inspire creativity Compromise Speaking protocols 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 18

10 JAD: Implementation Guidelines Clear and appropriate objectives in JAD meetings Commitment Objective facilitator, one that has no stake Facilitator should avoid offering opinions Inputs from participants before JAD Establish rules Don t let developers dominate meetings Effective communication tools 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 19 JAD: Advantages Reduces function creep by 50%, reduced by another 10-25% when used with prototyping (Cline, 2000) Increases quality, Reduces cost and development lifecycle time High degree of user involvement Promotes cooperation, understanding and teamwork 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 20

11 JAD: Disadvantages Meetings can be costly Group sessions needs skilful running to ensure group they are productive and reach a consensus Workshops tie up stakeholders often for several days at a time Appears to have only been used effectively for smaller-medium groups 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 21 Supporting Techniques: Prototyping Prototypes can be used to elicit requirements by allowing the user to see what the Requirements Engineer thinks the user needs clarify poorly understood requirements. understand how the user actually does the work develop user interfaces 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 22

12 Supporting Techniques: Use-Cases A collection of scenarios that describe the thread of usage of a system Each scenario is described from the point-of-view of an actor a person or device that interacts with the software in some way Each scenario answers the following questions: What are the main tasks of functions performed by the actor? What system information will the actor acquire, produce or change? What information does the actor require of the system? Does the actor wish to be informed about unexpected changes 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 23 Use Case UML Diagram User scenarios are an extremely powerful mechanism Analyze risks <<include>> <<include>> Valuation Trader Price details <<extend>> Currency Exchange Financial Officer Capture deal Client DB TSX 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 24

13 Requirements Engineering Process(Roadmap) Process Requirements Elicitation Requirements Analysis and Negotiation Requirements Specification Requirements Validation & Verification Requirements Management 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 25 Requirements Analysis & Negotiation Requirements analysis is to determine conflicts, ambiguity, inconsistencies, missing requirements or extra requirements Negotiation between all stakeholders then occurs to arrive at a set of agreed upon requirements Requirements analysis and elicitation are very closely interleaved Paralysis Through Analysis When do you know you are done? Determine the appropriate level of abstraction and decomposition? 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 26

14 Organizing Requirements Part of analysis is to begin organizing the requirements into functional areas Some techniques: Use Scenarios (Use Cases) Function/Attribute Categorization Interrelationship Digraphs 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 27 Prioritizing Requirements There is never enough time to build the ultimate system Requirements will have to be prioritized to ensure that the most important requirements are completed o Prioritizing requirements play an important role in ensuring the success of the Requirements Engineering activity Techniques that can be used for this are Analytical Hierarchy Worth-Cost Graph 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 28

15 System Modeling An important part of the analysis effort is to model the system to understand what you are trying to build There are many system modeling techniques that can be used Structured Analysis and Structured Design (SASD) Object Oriented Analysis and Design (OOAD) System models supplement the natural language description of the software system System models can be developed at many levels of abstraction and detail It is important to determine the appropriate level 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 29 Requirements Engineering Process(Roadmap) Process Requirements Elicitation Requirements Analysis and Negotiation Requirements Specification Requirements Validation & Verification Requirements Management 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 30

16 Requirements Specification Requirements specification is the activity to record the requirements in one or more forms, such as Software Requirements Specification (SRS) document The requirements may be in o o o Remember: natural language, a formal language, or/and in a graphical form SRS is used to communicate the requirements to several people with various interest o customers, end-users, managers, designers, and system developers 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 31 Requirements Specification(Cont.) Recall that SRS can be many things to many people It describes what the system will be to the users Requirements definition Requirements specification Software specification It describes what kind of system the design team need to build It describes what kinds of things need to be tested for the testing team Client managers System end-users Client engineers Contractor managers System architects System end-users Client engineers System architects Software developers Client engineers (perhaps) System architects Software developers It is important to have a standardized template for SRS documents Provides consistency and a checklist to ensure that all things are considered You can create your own standard or use an industry standard, such as IEEE Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 32

17 Requirements Engineering Process(Roadmap) Process Requirements Elicitation Requirements Analysis and Negotiation Requirements Specification Requirements Validation & Verification Requirements Management 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 33 Requirements Validation & Verification It is the activity to check requirements for o omitted, extra, wrong, and inconsistent requirements There are two concerns 1. are the stated requirements correct? (validation) 2. are the requirements stated correctly? (verification) Also to ensure that all requirements follow stated quality standards Requirements Inspections Inspections can be very effective in discovering inconsistencies, omissions, commissions, ambiguities, etc. Checklists can be developed to ensure that the requirements are valid 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 34

18 Requirements Management It is a change control to manage changing requirements during the development of the software system Managing requirements is an ongoing process that occurs through out the project life-cycle Configuration control systems can be used to help in this endeavor 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 35 Requirements Engineering Process(Roadmap) Process Requirements Elicitation Requirements Analysis and Negotiation Requirements Specification Requirements Validation & Verification Requirements Management 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 36

19 Software Requirements Specification IEEE 830- SRS 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 37 Software Requirements Specification (Review) SRS contains a complete description of the functionality of the system to be built It contains both functional and non-functional requirements all the software requirements, diagrams, system models and other supporting information It is the end result of the Requirements Analysis phase It also serves as a baseline for the downstream phases 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 38

20 IEEE STD IEEE Recommended Practice for Software Requirements Specifications Example: IFCAP VISN/Integration Software Requirements Specification Draft 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 39 IEEE 830- SRS :General Form 1 Introduction 1.1 Purpose of SRS 1.2 Scope of product 1.3 Definitions, acronyms, abbreviations 1.4 References 1.5 Overview of the rest of the SRS 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 40

21 IEEE 830- SRS SRS (Cont.) 2 General description 2.1 Product perspective 2.2 Product functions 2.3 User characteristics 2.4 General constraints 2.5 Assumptions and dependencies 3 Specific Requirements Appendices 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 41 IEEE 830- SRS: Section Functional requirements Functional requirement Introduction Inputs Processing Outputs Functional requirement n Functional requirement n 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 42

22 IEEE 830- SRS: Section 3(Cont.) External interface requirements User interfaces Hardware interfaces Software interfaces Communications interfaces 3.3 Performance requirements 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 43 IEEE 830- SRS: Section 3(Cont.) Design constraints Standards compliance Hardware limitations Attributes Availability Security Maintainability Transferability/conversion 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 44

23 IEEE 830- SRS: Section 3(Cont.) Other requirements Database Operations Site adaptation 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 45 Roadmap Fundamentals of Requirement Engineering Functional, Non-Functional & Domain Requirements Requirements Engineering Process Software Requirements Specification IEEE 830 SRS Standards Good SRS Document 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 46

24 Characteristics of a Good SRS 1. Correct 2. Unambiguous, Precise, and Clear 3. Complete 4. Verifiable & Testable 5. Consistent 6. Deal only with the problem 7. Feasible 8. Modifiable 9. Traceable 10. Use an appropriate specification language 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 47 Correct Each requirement in the SRS is free from error Each requirement statement accurately represents the functionality required of the system to be built e.g., o A problem domain states that ABC system is to recover from a crash within 5 minutes, However, in the SRS Document R123: ABC will >>>> recover within 10 minutes <<<< the requirement is in error 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 48

25 Unambiguous, Precise, and Clear Rxxx: The user interface shall be windows-based Each requirement in the SRS is exact and unambiguous There is one and only one interpretation for every requirement Never assume that everyone will understand the requirement the way you do When writing the requirement, try to imagine that the requirement is to be given to ten people who are asked for their interpretation At least, all terms that may have multiple meanings should be defined in a glossary The meaning of each requirement is easily understood and is easy to read Requirement statements should be short, explicit, precise and clear 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 49 Complete Save to file (Y/N)?: Q An SRS is considered complete if all requirements have been defined, and the SRS is complete as a document this includes functional and non-functional requirements Usually, it is a difficult to determine, because it requires a complete understanding of the problem domain It is complicated by the implication that something is missing in the SRS, and it is not a simple process to find something that is not present by examining what is present 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 50

26 Complete(Cont.) However, it will be helpful to conform to the applicable SRS standard If a particular section is not applicable, the SRS should include the section number and an explanation of why it is not applicable All pages are numbered; all figures and tables are numbered, named and referenced; all terms and units of measure are provided; and all referenced material, and sections are present. This is completeness from a wordprocessing perspective No sections are marked (TBD) 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 51 Verifiable and Testable An SRS is verifiable if and only if every requirement statement is verifiable o A requirement is verifiable if and only if there is some finite cost-effective way in which a person or machine can check if the software product meets the requirements When looking at the testability of a requirement consider if it can be tested by actual test cases, analysis or inspection 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 52

27 Example An unverifiable requirement o The system should be easy to use by experienced controllers and should be organized in such a way that user errors are minimized A verifiable requirement o o 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 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 53 Consistent Inconsistency can manifest itself in various ways: Conflicting terms o Two terms are used in different contexts to mean the same thing e.g., The term in one requirement, prompt is used to denote a message to have a user input data, In another, the term cue is used to mean the same thing Conflicting characteristics o Two requirements in the SRS demand the software to exhibit contradictory attributes One requirement states all inputs shall be via a menu interface Another, states all inputs shall be via a command language 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 54

28 Consistent(Cont.) Temporal or logical inconsistency: o Two parts of the SRS might specify conflicting timing characteristics or logic, e.g., One requirement may state that interrupt A will only occur when condition B is running At the same time, another states that condition B will run after interrupt A occurs A logic inconsistency may be one requirement stating that the software will multiply the inputs, another requirement may state that the software will add the inputs o Inconsistency can also occur between the requirements and their source It is important to insure that the terminology used is the same as the terminology used in the source documents 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 55 Deal Only With The Problem Client and server shall communicate over an IP network The SRS should not obscured by design detail It should state "what" is required at the appropriate system level Avoid telling the designer "how" to do the job, instead state "what what" has to be accomplished It must be detailed enough to specify "what" is required, yet provide sufficient freedom so design is not constrained 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 56

29 Feasible Each requirement in the SRS can be implemented with the available techniques, and resources, and within the specified cost and schedule constraints Set performance bounds based on system requirements Not on state-of-the-art capability 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 57 Modifiable Modifiability is structure and style aspect of the SRS document Not directly related to the actual requirements themselves An SRS is modifiable if its structure & style are such that any necessary changes to the requirements can be made easily, completely, and consistently Modifiability of an SRS requires the following: The SRS has a coherent and easy-to-use organization, with a table of contents, an index, and cross-references if necessary o This will allow easy modification of the SRS in future updates The SRS should have no redundancy, o i.e., a requirement should not be in more than one place in the SRS 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 58

30 Traceable An SRS is traceable if the origin of each of its requirements is clear and if it facilitates the referencing of each requirement in future development or enhancement documentation Each requirement should be contained in a single, numbered paragraph so that it may be referred to in other documents Preferably the requirement should be titled as well Grouping of several requirements in a single paragraph should be avoided unless interrelated requirements cannot be separated and still provide clarity This will facilitate backward traceability to source documents and forward traceability to software design documents and test cases 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 59 Traceable(Cont.) Backward traceability implies that we know why every requirement in the SRS exists Forward traceability Each requirement explicitly references its source in previous documents implies that all documents that follow the SRS are able to reference the requirements This is done by each requirement in the SRS having a unique name or reference number 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 60

31 SRS: Language Issues It is recommended to use "shall" statements, a directive to express what is mandatory The use of "shall" requires a sense of commitment Unwillingness to make such a commitment may indicate that o the requirement, as currently stated, is too vague, or o stating "how" and not "what", etc. It is not recommended to use "will, should and may" unless absolutely necessary "Will" statements imply a desire, wish, intent or declaration of purpose "Should" or "may" are used to express non-mandatory provisions 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 61 Characteristics of a Good SRS 1. Correct 2. Unambiguous, Precise, and Clear 3. Complete 4. Verifiable & Testable 5. Consistent 6. Deal only with the problem 7. Feasible 8. Modifiable 9. Traceable 10. Use an appropriate specification language 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 62

32 Summary Fundamentals of Requirement Engineering Functional, Non-Functional & Domain Requirements Requirements Engineering Process Software Requirements Specification IEEE 830 SRS Standards Good SRS Document 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 63