Please enable JavaScript.
Coggle requires JavaScript to display documents.
REQUIREMENTS ENGINEERING PROCESSES (Validation download (1) (Review…
REQUIREMENTS ENGINEERING PROCESSES
Elicitation & Analysis
Definition
:pencil2:
To find out about app domain, service provide & constraints
May involve stakeholders
Problems
:question:
Fail to get the exact req from stakeholder
Req change during analysis process
Conflicting req between stakeholders
Organisational & political factors
Stage
:
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
Techniques :hammer_and_wrench:
: :star:
Interviewing
Type
Mix of closed and opened interview
Closed interview
Open-ended interview
Good for get overall understanding stakeholder req
Not good for understanding domain req
:star:
Scenarios
Include
Description of starting situation
Desc of normal flow of event
Desc what can go wrong
Info about other concurrent activities
How the scenario finishes
Definition
Real-life example of how a system can be used
:star:
Use Case
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
:star:
Ethnography
Social scientist spends time observing and analyzing how people work
People do not have to explain about their work
Scope
Req derived from the way that people actually work
Req derived from cooperation and awareness
Understand existing process but cannot identify new features
Management
Definition
:pencil2:
Managing the changing of the requirement during the RE process & system development
to make the system is successful.
Function
:red_flag:
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:
Changing Requirement
:black_flag:
:check:
Business and technical environment
always changes after installation. Business priorities may changes and new regulation may be introduced.
:check:
System customers impose requirement because of organizational and budget constraints.
May have conflict with end-user requirements.
:check:
Large systems have diverse user community
. The final system need to be balanced to support all different types of users.
Validation
Requirements Reviews
:eyes:
Formal
:check: With completed documents.
Informal
:green_cross: With not completed documents.
Technique
:hammer_and_wrench:
Requirements reviews
:pencil2: Systematic manual analysis
Prototyping
:pencil2: Use an executable model of system to check requirements.
Test-case generation
:pencil2: Develop test to check testability.
Review Checking
:checkered_flag:
Verifiability
:question: Is the requirement realistically
testable?
Comprehensibility
:question: Is the requirement properly
understood?
Traceability
:question: Is the origin of the requirement
clearly stated?
Adaptability
:question: Can the requirement be changed
without a large impact on other requirements?
Definition
:pencil2:
Concerned with demonstrating that the requirements define the system as what the customer really wants.
:warning: validation is important.
Requirements Checking
:checkered_flag:
Consistency
:question: Are there any requirements
conflicts?
Completeness
:question: Are all functions required by the
customer included?
Validity
:question: Does the system provide the functions
which best support the customer’s needs?
Realism
:question: Can the requirements be implemented
given available budget and technology?
Verifiability
:question: Can the requirements be checked?
