02- Software Requirements

Software Requirements

Prepared By: Eng.\ Tarig Eng.\ Tarig Ahmed Khalid, M.Sc ., ., PM P , CBAP , CE CEC C I T/ Pr ojec ojectt M anage anageme ment/ nt/ B us usii nes ness s An alys alysii s Cons Consul ul tant & Tr Train ain er

Trusted by over 1 million members

Try Scribd FREE for 30 days to access over 125 million titles without ads or interruptions! Start Free Trial Cancel Anytime.



















Introduction  The Software Requirements Knowledge Area (KA) is concerned

with: 1. Requirements Elicitation

2. Requirements Requirements Analysis 3. Requirements Specification 4. Requirements Validation





















1. Software Requirements Fundamentals 2. Requirements Process 3. Requirements Requirements Elicitation 4. Requirements Analysis 5. Requirements Requirements Specification





















1. Software Requirements Fundamentals 2. Requirements Process 3. Requirem Requirements ents Elicitation 4. Requirements Analysis 5. Requirem Requirements ents Specification





















1.1 What is a Requirement? Requirement?  A requirement is:

1. A condition condition or or capability capability needed needed by a stakeholder a stakeholder to: to:

a. solve a problem, or b. achieve an objective 2. A condition or capability that must be met or possessed by a condition or capability that solution or solution component to satisfy a : a. contract, b. standard,





















1.2 What is a Software Requirement? Requirement? a property which which must be exhibited in  Software requirement is a property

order to solve some problem in the real world.  Software requirement is a property which must be exhibited by

software developed or adapted to solve a particular problem. r equirements is that they must  An essential property of all software requirements























1.3 Importance 1.3 Importance of Requirements  Requirements Management can be an extremely complex

discipline because of: 1. the numbers of stakeholders involved in the development process























v ery  Poor requirements management is likely to lead to some very costly mistakes.























1.4 Types 1.4 Types of Requirements  Requirements are classified into:

1. Business Requirements 2. Stakeholders Requirements























1.4.1 Business 1.4.1 Business Requirements statements of the goals the goals,, objectives objectives,, or needs needs of of the  Are higher-level statements enterprise.























1.4.2 Stakeholders’ Requirements Are statements of the needs of a particular stakeholder or class of  Are statements stakeholders.  They describe:

























1.4.3 Solution 1.4.3 Solution Requirements























a. Functional Requirements























1.4.4 Transition 1.4.4 Transition Requirements























1.5 Emergent 1.5 Emergent Properties























1.6 Quantifiable 1.6 Quantifiable Requirements





























































































































































































































































































Communication Modes





















Techniques 1. Document Analysis 2. Interface Analysis 3. Prototyping 4. Observation 5. Interviews 6. Brainstorming 7. Focus Groups





















About Elicitation Techniques  Is this a single or multi-stakeholder environment? o

More difficult in multi-stakeholder environment environment

o

Challenging if no consensus

o

The SE role is not to make decisions about which requirement is “right “right”, ”, but to create the right conditions and to facilitate the sessions

 Are all the stakeholders located together ?





















Different Techniques For Different Stakeholders 1. Working With Executives:  Need to be more conservative with the time they need to spend

with the project

flexible with with scheduling  Need to be flexible 2. Working With The Users Of The System: while they they are performing  May need to spend time with them while their work  May need to show them different scenarios in a prototype





















3.2.1 Document Analysis  One of the best way to prepare for upcoming events

Is, no requirements about the  Provides information about the As Is, To Be.  Source of information:  System documentation  Enhancement requests  Problem logs  User manuals























3.2.1 Interfaces Analysis  Most of the systems built today will need to interface other

systems.

May not be enough to only ask the stakeholders about it, they























3.2.3 Prototyping 3.2.3 Prototyping abstractness (unlike (unlike other techniques)  Dramatically reduces abstractness objectives about about the prototyping scope  Establish realistic objectives  Establish realistic expectations, expectations, it is just a prototype

evolve:  You may use 2 types of prototypes regarding how it will evolve:























3.2.4 Interviews 3.2.4 Interviews  May be self-standing technique or a part of another technique  Can be:

– Open ended – ended – the the interviewer starts with predefined questions and continues the interview based on the input – Close ended (a survey) interview – interview – the the entire interview is guided by























Types of Questions  Open ended (“tell (“tell me about ...”) ...”)  introduce topics that the interviewer

may not have been aware of.  Risks: Stakeholder may loose focus or may not be comfortable with. (“Do you perform XYZ today?”) today? ”) – they they keep the  Close ended (“Do interviewee focused. Many of these questions will come naturally as a























3.2.5 Observation 3.2.5 Observation  Can be done

(interacting with the stakeholder )  Actively (interacting (using video records or one-way mirrors) mirrors )  Passively (using

























3.2.6 Focus 3.2.6 Focus Group























3.2.7 Brainstrorming 3.2.7 Brainstrorming













































3.2.8 Requirements 3.2.8 Requirements Workshops























Workshop Roles





























































































































































































































































































5.3 Software 5.3 Software Requirements Specification  Software requirements specification establishes the basis for

agreement between between customers customers and and contractors contractors or or suppliers on what the software product is to do, do, as well as what it is not not to to do. do.  For non-technical readers, the software requirements specification

document is often accompanied by a software requirements definition document.





















IEEE/ANSI 830-1993 Standard Documentation 1. Introduction 1.1 Purpose 1.1 Purpose of requirements document 1.2 Scope 1.2 Scope of the product 1.3 Definitions, 1.3 Definitions, acronyms and abbreviations 1.4 References 1.4 References 1.5 Overview 1.5 Overview of the remainder of the document 2. General description 2.1 Product perspective 2.2 Product 2.2 Product functions 2.3 User 2.3 User characteristics





















Writing Essentials 1. Requirements Requirements are read more often than they are written. You should invest time to write readable readable and and understandable requirements 2. Do not assume that all readers of the requirements have the same background and use the same terminology as you 3. Allow time for review, revision and re-drafting re-d rafting of the requirements document

Writing Guidelines 1. Define standard templates for describing requirements 2. Use language simply consistently and concisely





















Document Usage System Customers

Managers

System Engineers

Specify requirements and read them to check that they meet the changes changes.. They also specify changes to the requirements Use the requirements documents to plan to plan a a bid for the system and to plan the system development process. Use the requirements to understand what what system is to be developed.





















1. Software Requirements Fundamentals 2. Requiremen Requirements ts Process 3. Requiremen Requirements ts Elicitation 4. Requirements Analysis 5. Requiremen Requirements ts Specification























6.0 Definitions 6.0 Definitions 

Requirements validation is concerned with the process of examining the the requirements document to ensure that it defines the right software (that (that is, the software that the users expect). expect ).



The requirements documents is subject to validation and























Verification VS. Validation

 Verifying  Doing the things right























6.1 Requirements 6.1 Requirements Reviews  The most common means of validation is by inspection or reviews

of the requirements documents. errors,, mistaken assumptions, assumptions, lack of  Reviewers should look for errors























6.2 Prototyping 6.2 Prototyping  Is also used to validate the SE’s interpretation of the software

requirements  Advantage: they can make it easier to interpret the software

engineer’s assumptions assumptions and, where needed, give useful feedback on why they are wrong.























6.3 Characteristics of Good Requirements that the requirements should be Complete,  It is essential that Clear, Correct, and Consistent (4 (4 Cs). Cs).

























Other Characteristics…























6.4 Acceptance 6.4 Acceptance Tests













































7.0 Introduction 7.0 Introduction























7.1.. Iterative Nature of the Requirements 7.1







































































































































































02- Software Requirements

Recommend Documents