REQUIREMENTS ENGINEERING PROCESSES (Validation download (1) (Review…
REQUIREMENTS ENGINEERING PROCESSES
Elicitation & Analysis
To find out about app domain, service provide & constraints
May involve stakeholders
Fail to get the exact req from stakeholder
Req change during analysis process
Conflicting req between stakeholders
Organisational & political factors
1. Requirement discovery
Interact with stakeholder to discover their requirement
2. Req classification and organization
Group related requirement and organize them
4. Req specification
Req are documented and input into next round of the spiral
3. Prioritising and negotiation
Prioritize and resolving requirement
Mix of closed and opened interview
Good for get overall understanding stakeholder req
Not good for understanding domain req
Description of starting situation
Desc of normal flow of event
Desc what can go wrong
Info about other concurrent activities
How the scenario finishes
Real-life example of how a system can be used
Scenario based technique in UML that identify actors in an interaction and describe the interaction itself
High-level graphical model supplemented by detailed tabular description
Describe all possible interaction
Social scientist spends time observing and analyzing how people work
People do not have to explain about their work
Req derived from the way that people actually work
Req derived from cooperation and awareness
Understand existing process but cannot identify new features
Managing the changing of the requirement during the RE process & system development
to make the system is successful.
Keep track the individual requirement & maintain, so RE can access the impact of requirement changes. :pen:
Establish a formal process for making change proposals and linking to system requirements. : :pen:
Business and technical environment
always changes after installation. Business priorities may changes and new regulation may be introduced.
System customers impose requirement because of organizational and budget constraints.
May have conflict with end-user requirements.
Large systems have diverse user community
. The final system need to be balanced to support all different types of users.
:check: With completed documents.
:green_cross: With not completed documents.
:pencil2: Systematic manual analysis
:pencil2: Use an executable model of system to check requirements.
:pencil2: Develop test to check testability.
:question: Is the requirement realistically
:question: Is the requirement properly
:question: Is the origin of the requirement
:question: Can the requirement be changed
without a large impact on other requirements?
Concerned with demonstrating that the requirements define the system as what the customer really wants.
:warning: validation is important.
:question: Are there any requirements
:question: Are all functions required by the
:question: Does the system provide the functions
which best support the customer’s needs?
:question: Can the requirements be implemented
given available budget and technology?
:question: Can the requirements be checked?