Software Development Module Code: CST 240 Chapter 3: Requirement Analysis Dr. Husam Osta 2013.
-
Upload
brett-gerald-thornton -
Category
Documents
-
view
234 -
download
0
Transcript of Software Development Module Code: CST 240 Chapter 3: Requirement Analysis Dr. Husam Osta 2013.
Outline• Requirements Engineering• Functional/non-functional requirements• Feasibility study• Requirements elicitation and analysis • Requirements validation• Requirements management C
hapt
er 3
: Req
uire
men
t A
naly
sis
2
Requirements Engineering
• The process of eliciting, analysing, documenting, and validating the services required of a system and the constraints under which it will operate and be developed.
• Descriptions of these services and constraints are the requirements for the system.
Cha
pter
3: R
equi
rem
ent
Ana
lysi
s
3
Requirements Engineering
Cha
pter
3: R
equi
rem
ent
Ana
lysi
s
4
Involves a variety of people in an organization, such as:
• System end users and their managers.
• Engineers who are developing or maintaining other related systems.
• Trade union representatives.
• Others in the organization who will be affected by the system.
• All of the above are called stakeholders
Requirements engineering
• Requirements engineering is a difficult process because:• Stakeholders make unrealistic demands. • Requirements are expressed in stakeholders
language• Different requirements from different stakeholders• Political factors• Analysis Environment
Cha
pter
3: R
equi
rem
ent
Ana
lysi
s
5
Software System Requirement
• Software System Requirements can be classified as • Functional Requirement:
are the services the system should provide and what the software should do.
• Nonfunctional Requirement: arise through user needs, because of budget constraints, because of organizational policies, because of the need for interoperability with other software or hardware systems, or because of external factors such as safety regulations or privacy legislation.
Cha
pter
3: R
equi
rem
ent
Ana
lysi
s
6
Types of Non-functional requirements
• Product requirements – specify product behaviour.
• Organizational requirements – derived from policies / procedures in customer’s or developer’s organization (e.g., process constraints).
• External requirements – derived from factors external to the product and its development process (e.g., interoperability requirements, legislative requirements). C
hapt
er 3
: Req
uire
men
t A
naly
sis
7
Non-Functional ClassificationsNon-Functional Classifications
Cha
pter
3: R
equi
rem
ent
Ana
lysi
s
8
Performancerequirements
Spacerequirements
Usabilityrequirements
Efficiencyrequirements
Reliabilityrequirements
Portabilityrequirements
Interoperabilityrequirements
Ethicalrequirements
Legislativerequirements
Implementationrequirements
Standardsrequirements
Deliveryrequirements
Safetyrequirements
Privacyrequirements
Productrequirements
Organizationalrequirements
Externalrequirements
Non-functionalrequirements
Performancerequirements
Spacerequirements
Usabilityrequirements
Efficiencyrequirements
Reliabilityrequirements
Portabilityrequirements
Interoperabilityrequirements
Ethicalrequirements
Legislativerequirements
Implementationrequirements
Standardsrequirements
Deliveryrequirements
Safetyrequirements
Privacyrequirements
Productrequirements
Organizationalrequirements
Externalrequirements
Non-functionalrequirements
Examples of non-functional requirements
• Product requirement:4.C.8 It shall be possible for all necessary communication between the system and the user to be expressed in the standard Ada character set.
• Organisational requirement:9.3.2 The system development process and deliverable documents shall adapt to the process and deliverables defined in XYZCo-SP-STAN-95.
• External requirement:7.6.5 The system shall not disclose any personal information about customers apart from their name and reference number to the operators of the system.
Cha
pter
3: R
equi
rem
ent
Ana
lysi
s
9
Difference between functional and non functional requirements Sl.No Functional Requirement Non-functional Requirement
1.Defines all the services or functions required by the customer that must be provided by the system
Defines system properties and constraints e.g. reliability, response time and storage requirements. Constraints are I/O device capability, system
representations, etc .
2.It describes what the software should do.It does not describe what the software will do, but how the software will do it .
3.Related to business. For example: Calculation of order value by Sales Department or gross pay by the Payroll Department
Related to improving the performance of the business. For example: checking the level of security. An operator should be allowed to view only my name
and personal identification code .
4.Functional requirement are easy to test .Nonfunctional requirements are difficult to test
5.Related to the individual system features Related to the system as a whole
6.Failure to meet the individual functional requirement may degrade the system
Failure to meet a non-functional requirement may make the whole system unusable .
Cha
pter
3: R
equi
rem
ent
Ana
lysi
s
10
Requirements Engineering Processes
• The processes used for RE vary widely depending on the application domain, the people involved and the organization developing the requirements.
• However, there are a number of generic activities common to most processes:• Feasibility study• Requirements elicitation (collection) and analysis• Requirements validation
Cha
pter
3: R
equi
rem
ent
Ana
lysi
s
11
Role of the feasibility study
• Identify alternatives • Analyse costs and benefits• Establish priorities• Present alternatives
Cha
pter
3: R
equi
rem
ent
Ana
lysi
s
12
Feasibility study• Determines whether or not the proposed undertaking
is worthwhile.
• Aims to answer three basic questions:1. Would the system contribute to overall organizational
objectives?2. Could the system be engineered using current technology
and within budget?3. Could the system be integrated with other systems
already in use?
Cha
pter
3: R
equi
rem
ent
Ana
lysi
s
13
Types of feasibility
1.1. Operational FeasibilityOperational Feasibility2.2. Technical FeasibilityTechnical Feasibility3.3. Schedule FeasibilitySchedule Feasibility4.4. Economic FeasibilityEconomic Feasibility
Cha
pter
3: R
equi
rem
ent
Ana
lysi
s
14
Types of feasibility1. Operational Feasibility
• Identify how complex is the problem and check if the given solution will solve the problem.
• It involves the analysis of:1. Performance (throughput, reliability, response time, and process
improvement).2. Control (security and protection against fraud).3. Efficiency : does the system make maximum use of available
resources.4. Ease of use and ease of learning.
– Will the solution fulfils the users’ requirements? To what degree?– How will the solution change the users’ work environment?– How do users feel about such a solution?
Cha
pter
3: R
equi
rem
ent
Ana
lysi
s
15
Types of feasibility2. Technical Feasibility
• Is the proposed technology or solution practical?• State-of-the-art (High-tech) technology vs. mature (old)
technology.• Do we currently possess the necessary technology?• Do we possess the necessary technical expertise?
3. Schedule Feasibility• Given the current technology and technical expertise, are the
project deadlines reasonable?• What happens if we don’t finish on time?
Cha
pter
3: R
equi
rem
ent
Ana
lysi
s
16
Types of feasibility4. Economic Feasibility
• Is the proposed system cost-effective?• What is the return-on-investment (ROI)? [ROI measures the magnitude of the benefits relative to the costs ]• What is the break-even point?
[Break-even point is the time from the first money spent until the development investment has been recovered. ]
Cha
pter
3: R
equi
rem
ent
Ana
lysi
s
17
The Requirement elicitation (collection) and analysis process
Cha
pter
3: R
equi
rem
ent
Ana
lysi
s
18
The Requirement elicitation and analysis process1. Domain understanding: develop an
understanding of the application domain. Involves working with stakeholders to learn about the application domain, the services needed and the system’s operational constraints
2. Requirements collection: the process of interacting with the stakeholders to discover requirements.
3. Classification: organize the unstructured collection of requirements into coherent clusters.
Cha
pter
3: R
equi
rem
ent
Ana
lysi
s
19
The Requirement elicitation and analysis process
4. Conflict resolution: finding and resolving conflicted requirements.
5. Prioritization: interacting with the stakeholders to discover the most important requirements.
6. Requirements validation: requirements are checked to discover if they are complete, consistent, and in accordance with what the stakeholders want from the system.
Cha
pter
3: R
equi
rem
ent
Ana
lysi
s
20
Requirements DiscoveryRequirement discovery is the formal process of collecting
information about problems, requirements, and preferences. It is also called information gathering or fact finding.
The different fact finding techniques include1- Observation: 2- Interviewing: 3- Questionnaires:4- Searching:.5- Sampling:
Cha
pter
3: R
equi
rem
ent
Ana
lysi
s
21
Requirements Discovery- Observation• Observation is a fact-finding technique wherein the systems analyst
either participates in or watches a person perform activities to learn about the system.
Cha
pter
3: R
equi
rem
ent
Ana
lysi
s
22
Requirements Discovery - InterviewsWhom to interviewA. Top level managers
• To confirm project team understanding of the business.• To get commitment for the project.
B. Middle level managers• To obtain greater understanding of the problem.• To define the requirements in general terms.
C. Operational managers• To get a full more detailed information of the problem.• To obtain the critical points about the work procedures.
Cha
pter
3: R
equi
rem
ent
Ana
lysi
s
23
Requirements Discovery – Interview types1. Unstructured interviews
• Informal, the interviewer develops the theme of the interview according to the answers.
• It is in the format of questions and answers.• Used when the analyst wants to get general information about the
business.
Cha
pter
3: R
equi
rem
ent
Ana
lysi
s
24
Requirements Discovery – Interview types
2. Structured interviews• Uses standardized predefined questions in either open response or
dead response format.• Uses a set of prescribed answers.• Used when the analyst wants to get full details about the business.
Cha
pter
3: R
equi
rem
ent
Ana
lysi
s
25
Requirements Discovery – Questionnaires• They are sets of predefined and standardized questions arranged on
a form to obtain information about a particular subject.• They are used for:
• Evaluating specific features of a system.• Investigate different opinions, knowledge, or attitudes towards
the system.• They are sent via: mail, fax, e-mail, or in-person.
• They should be made easy for the user to complete because:• If the user find the questions difficult, they might not complete
the questionnaire, which will result in low rate of return.• Avoid ambiguity, because ambiguous questions generate
unreliable answers.
Cha
pter
3: R
equi
rem
ent
Ana
lysi
s
26
Requirements Discovery – Types of Questions
• Open Ended [Free Format]• Close ended [Fixed Format ]• Mixed
• Open ended (or free format) : There is no predefined answers
• Example:
What types of computers do you currently have installed?name model qty
Cha
pter
3: R
equi
rem
ent
Ana
lysi
s
27
Requirements Discovery – Types of Questions
• Close Ended [Fixed format ]• Example:
• Multiple choice:
Which of the following cities would you like to live in?a)New Yorkb)Londonc)Parisd)Rome
• RatingDo you feel this class is important?
a) Strongly agree b) Agree c) No opinion d) disagree e) strongly disagree
Cha
pter
3: R
equi
rem
ent
Ana
lysi
s
28
Requirements Discovery – Types of Questions
• Mixed• Example:
In what type of business is your organization?1) Government 4) Trading2) Military 5) Others ( please specify)3) Industrial ____________________
Cha
pter
3: R
equi
rem
ent
Ana
lysi
s
29
InterviewQuestionnaireInterviews are conducted only with selected persons. Hence addresses a small group of people.
Address a large crowd
Probing and follow-up is easyLimited probing and follow-up done after collection of original data.
Interviewee is known to the interviewer
Respondents can be unknown
Unclear questions can be clarified by both the interviewer and the interviewee.
Unclear questions may not be clarified which my result in misunderstanding and wrong answers.
The information obtained will be rich.
The information may not be so rich.
Cha
pter
3: R
equi
rem
ent
Ana
lysi
s
30
Requirements Discovery - Searching
• All available written material that describes the business should be considered. In addition the documents that provide information should be catalogued for future reference.
Cha
pter
3: R
equi
rem
ent
Ana
lysi
s
31
Requirements Discovery - Searching
There are 3 groups of documents:
A. Business documents• Annual reports, business plans and forecasting,
organization chart, hand books, and advertising booklets.
B. Current system environment documents• System description, data administration
guidelines, system architecture documents, system flowcharts, database specifications, IT organizational chart, user manual.
Cha
pter
3: R
equi
rem
ent
Ana
lysi
s
32
Requirements Discovery - Searching
C. Current technical environment documents• Hardware distribution list, capacity planning
documents, system software list, network documents, performance statistics, hardware and software plans.
Cha
pter
3: R
equi
rem
ent
Ana
lysi
s
33
Requirements Discovery - Sampling• Sampling is the process of collecting a representative
sample of documents, forms, and records. • Randomization is a sampling technique characterized
as having no predetermined pattern or plan for selecting sample data.
• Stratification is a systematic sampling technique that attempts to reduce the variance of the estimates by spreading out the sampling—for example, choosing documents or records by formula—and by avoiding very high or low estimates.
Cha
pter
3: R
equi
rem
ent
Ana
lysi
s
34
Viewpoint-oriented analysis• For every system there are a group of stakeholders and each group
has different interest in the system, each interest is called a viewpoint.
• To illustrate viewpoints lets take the example of ATM stakeholders
Cha
pter
3: R
equi
rem
ent
Ana
lysi
s
35
ATM stakeholders• Bank customers• Representatives of other banks• Bank managers• Counter staff• Database administrators • Security managers• Marketing department• Hardware and software maintenance engineers• Banking regulators
Cha
pter
3: R
equi
rem
ent
Ana
lysi
s
36
Viewpoint-oriented analysisAny viewpoint may be considered as:1. A data source or sink
• In this case the analyst must identify what data is produced or consumed and what is the process of doing that.
• A cross-check is made to discover data being produced but not consumed or vice versa.
• Used by the CORE method.
Cha
pter
3: R
equi
rem
ent
Ana
lysi
s
37
Viewpoint-oriented analysis2. A representation framework
• In this case, each viewpoint is represented by a different data model.
• The data models are cross-checked to discover requirements that would be missed.
• Used by the VOSE method
Cha
pter
3: R
equi
rem
ent
Ana
lysi
s
38
Requirement Validation• Requirements validation is an activity that checks the
requirements definition document for accuracy, completeness, consistency, and conformance to standards.
• Concerned with whether or not the requirements define a system that the customer really wants.
• Requirements error costs are high, so validation is very important.
Cha
pter
3: R
equi
rem
ent
Ana
lysi
s
39
Requirements checking• Validity. Does the system provide the functions which
best support the customer’s needs?• Consistency. Are there any requirements conflicts?• Completeness. Are all functions required by the
customer included?• Realism. Can the requirements be implemented given
available budget and technology• Verifiability. Can the system be tested to determine
whether or not the requirements are met?
Cha
pter
3: R
equi
rem
ent
Ana
lysi
s
40
Requirements validation techniques• Requirements reviews / inspections – systematic manual analysis of
the requirements.• Prototyping – using an executable model of the system to check
requirements. • Test-case generation – developing tests for requirements to check
testability.• Automated consistency analysis – checking the consistency of a
structured requirements description.
Cha
pter
3: R
equi
rem
ent
Ana
lysi
s
41
Requirements management• Requirements management is the process of managing changing
requirements during the requirements engineering process and system development.
• New requirements emerge during the process as business needs change and a better understanding of the system is developed.
Cha
pter
3: R
equi
rem
ent
Ana
lysi
s
42
Requirements management• The priority of requirements from different viewpoints changes
during the development process.• The business and technical environment of the system changes
during its development.
Cha
pter
3: R
equi
rem
ent
Ana
lysi
s
43