Software Requirement Engineering Notes
Software Requirement Engineering Notes
Domain Req.
o Constraints on the system from the domain of the operation
o Problems:
Understandability
Req. expressed in language of the application domain
Implicitness
Domain specialist understand the area so well that
they do not think of making the domain req. explicit.
Waterfall
Incremental
Agile processes
Planning is incremental and it is easier to change the process
to reflect changing customer requirements.
Principle
XP Practices
RE Process Variability
o Vary radically from one organization to another
o Factors
Technical maturity
Disciplinary involvement
Organizational culture
Application domain
5. Requirements Elicitation & Analysis
- Req. gathering/Req. discovery
- Involves technical staff working with customer to find out about
application domain, the services that the system should provide & the
systems operational constraints.
- May involve end-users, managers, engineers involved in maintenance,
domain experts, trade unions (STAKEHOLDERS)
- Types of Stakeholder
o Software engineers responsible for system development
o System end-users who will use the system after it has been
delivered
o Managers of system end-users who are responsible for their work
o External regulators who check that the system meets its legal
requirements
o Domain experts who give essential background information about
the system application domain
- Stages in Req. Elicitation & Analysis Process
o Req. discovery
Interacting with
stakeholders to discover
their req.
Domain req. are also
discovered at this stage
o Req. classification &
organization
Groups related
requirements and
organizes them into
coherent clusters
o
o
Req.
Req.
Problems:
o Stakeholders dont know what they really want.
o Stakeholders express req. in their own terms.
o Different stakeholders may have conflicting req.
o Organizational and political factors may influence the system req.
o The req. change during the analysis process. New stakeholders may
emerge and the business environment change
6. Req. Validation
- Concerned with demonstrating that the req. define the system that the
customer really wants
- Criteria:
o Validity. Does the system provide the functions which best support
the customers needs?
Consistency. Are there any requirements conflicts?
Completeness. Are all functions required by the customer
included?
o Realism. Can the requirements be implemented given available
budget and technology
o Verifiability. Can the requirements be checked?
Techniques:
o Requirements reviews
Systematic manual analysis of the requirements.
o Prototyping
Using an executable model of the system to check
requirements.
o Test-case generation
Developing tests for requirements to check testability.
Req. Reviews
o Regular review should be held while req. definitions is being
formulated.
o Involved the client & contractor staff
o Reviews may be formal/informal
o Review Checks
Verifiability
Is the requirement realistically testable?
Comprehensibility
Is the requirement properly understood?
Traceability
Is the origin of the requirement clearly stated?
Adaptability
o
o
7. Req. Management
- Process of managing changing req. during the req. eng. Process & system
dev.
- New req. emerge as system being dev
- Changing Req.
o Business & technical environment of the system always changes
after installation
o The people who pay the system & user are not the same people
- Change Analysis & Costing
Req. Evolution
Types of Traceability
Req.-sources traceability
Links the req. and the people or documents which
specified the req.
Req.-rationale traceability
Links the req. with a description of why that req. has
been specified.
Req.-req. traceability
Links req. with other req. which are, in some way,
dependent on them. This should be a two-way link
(dependents and is dependent on).
Req.-architecture traceability
Links req. with the sub-systems where these req. are
implemented. This is particularly important where subsystems are being developed by different subcontractors
Requirements-design traceability
Req.
8. RE Process Problems
- Lack of stakeholder involvement
- Business needs not considered
- Lack of requirements management
- Lack of defined responsibilities
- Stakeholder communication problems
- Over-long schedules and poor quality requirements documents
Schedule Feasibility
Economic Feasibility (cost-benefit analysis)
Objective Setting
o An outline descriptions of the problem to be solved, why the system is
necessary & constraints on the system.
- Background knowledge
acquisition
o Background info about system,
the application domain of the
system & info about existing
systems.
- Knowledge organization
o The information collected need
to be organized & collated.
- Stakeholder req. collection
o System stakeholders are
consulted to discover their requirements
3. Req. Analysis & Negotiation
- Req. Analysis
o Necessity checking
o
o
- Req. Negotiation
o Req. Discussion: problematic req. being discussed
o Req. Prioritization: identify critical req.
o Req. Agreement: solution to req. problems are identified
4. Elicitation Techniques
- Specific techniques which may be used to collect knowledge about system
req.
- Structure of knowledge:
o Partitioning - aggregating related knowledge
o Abstraction - recognizing generalities
o Projection - organizing according to perspective
- Elicitation problems
o Not enough time for elicitation
o Inadequate preparation by engineers
o Stakeholders are unconvinced of the need for a new system
- Elicitation Methods
o Interviews
Formal/informal interviews with stakeholder
Type of interview
Closed interview: based on pre-determined list of
questions
Open interview: various issues are explored with
stakeholders
Effective interviewing
Be open-minded, avoid pre-conceived ideas about req. &
listen to stakeholder
Prompt interviewee to get discussing, req. proposal,
working together on prototype
o Scenarios
Based on real-life stories/examples of how a system can be
used.
Include:
Description of starting situation
Description of normal flow of events
Description of what can go wrong
Info about other concurrent activities
Description of the state when scenario finishes
o
o
o
5. Req. Analysis
- To discover problems, incompleteness & inconsistencies in the elicited req.
- Interleaves with elicitation as problems are discovered when the req. are
elicited
- Problem checklist may be used to support analysis.
- Analysis Checklist
o Premature design
Does the req. include premature design or implementation
information?
o Combined req.
Does the description of a req. describe a single req. or could it
be broken down into several different req.?
o Unnecessary req.
Is the requirement gold plating? That is, is the requirement a
cosmetic addition to the system which is not really necessary?
o Use of non-standard hardware
Does the req. mean that non-standard hardware or software
must be used? To make this decision, you need to know the
computer platform req.
o Conformance with business goals
Is the req. consistent with the business goals defined in the
introduction to the req. document? Req. ambiguity
o Req. ambiguity
Is the requirement ambiguous i.e. could it be read in different
ways by different
people? What are the possible interpretations of the req.?
o Req. realism
Is the req. realistic given the technology which will be used to
implement the system?
o Req. testability
Is the req.t testable, that is, is it stated in such a way that test
engineers can derive a test which can show if the system meets
that req.?