Scribd
Upload
21 views15 pages

Requirements Elicitation and Analysis

Software engineering

Uploaded by

Haris Nadeem
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
21 views15 pages

Requirements Elicitation and Analysis

Software engineering

Uploaded by

Haris Nadeem
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 15

Requirements

Elicitation and
Analysis
Sommerville Book: Sections 4.5 and 4.6
• In this activity, software engineers work with the customers and end-
users to elicit the requirements
• It may involve different stakeholdes
• a stakeholder is a person who should have direct or indirect influence on the
system requirements
• Following are the main activities in the requirements elicitation and
analysis process:
• requirements discovery
• requirements classification and organization
• requirements prioritization and negotiation
• requirements specification
Challenges of Requirements
Elicitation
• Stakeholders often have a high-level vision of the system
• they may not be able to articulate exactly what they expect from the system
• Stakeholders may not describe many important aspects
• they take for granted this knowledge
• Requirements engineers have to discover commonalities and conflicts
among the requirements elicited from different stakeholders
• Political factors may try to influence requirements
• The economic and business environment may change the priorities of
the requirements
Requirements Discovery
• It is also called requirements elicitation
• We elicit requirements from stakeholders
• They also come from:
• the application domain
• other systems that interact with the application
Interviewing
• They are one of the most common techniques for requirements
elicitation
• Interviewer asks questions about:
• the current system that is being used
• the proposed system
• A closed interview has pre-defined questions
• An open interview has no pre-defined agenda
• Typically, interviews are a mix of the both
• It has the following limitations:
• Interviewees may not communicate implicit domain knowledge
• Interviewees may not communicate the actual power structure to an outsider
• Interviewer may misunderstand the domain-specific terminology
• An interviewer must be:
• open-minded without any pre-conceived ideas about requirements
Use Cases
• A use case is a scenario of how a user will interact with the system
• They help in adding detail to the outline requirements
• A typical scenario may include:
• what are the expectations at the start of the scenario
• normal flow of events
• what can go wrong and how to handle it
• any other parallel activities
• what would be the system state at the end of the scenario
• A use case diagram presents an overview of the system
• how each role interacts with the system
• Prepare a couple of use cases for your project
Ethnography
• A software system is used in a social and organizational context
• and its requirements may be constrained by these contexts
• Lack of consideration of these contexts may make a system unusable
• Contrary to our assumptions, actual work practices at the workplaces are
often
• far richer
• more complex
• more dynamic
• In ethnography, an anlyst immerses itself into the target working
environment of the system
• It helps to elicit requirements not implicitly stated by the stakeholders
• Ethnography can be combined with prototyping to reduce the refinement
cycles
• Prototyping may focus the ethnographic studies
• Becuase of the focus of ethnography on end-users, it may not be suitable
for discovering:
• organizational requirements
• domain requirements
• Therefore, we should use it in combination with other elicitation techniques

• Think of your target environment and plan an ethnographic study


Requirements Validation
• It is the process of checking that requirements actually define the system
that the customer really wants.
• It is concerned with finding problems with the requirements
• Problems in requirements may lead to extensive rework costs
• Following types of checks should be carried out:
• Validity checks: The proposed system will meet the stakeholder needs
• Consistency checks: Requirements should not conflict
• Completeness: Include all functions and domains by the system users
• Realism checks: Ensure that the proposed system can be implemented
• Verifiability: Write requirements in a way so that the developed system may be
verified against them
• Following are the requirements validation techniques:
• Requirements reviews
• Prototyping
• Test case generation
• There may still be problems left in the requirements document even
after the requirements validation.
Requirements Management
• The requirements for a large system almost always change
• Once the system is installed and operational:
• new requirements emerge
• end-users may discover new needs and priorities
• Following are the reasons of changing requirements:
• Changes in business and technical environment
• System customers impose requirements because of organizational and
budgetary constraints, which may be in conflict with end-user requirements
• Large systems have diverse user community, with likely conflicting
requirements
• Requirements management is the process of understanding and
controlling the changes in requirements

You might also like