Unity University
College of Engineering, Technology and Computational
Science
Department of Computer Science and MIS
Course: Systems Analysis and Design an Object Oriented
Approach with UML
Assignment on:
REQUIREMENTS ANALYSIS STRATEGIES
REQUIREMENTS VALIDATION AND VERIFICATION
By: ID.NO:
ABENEZER G/KIRSTOS: UU93893R
Instructor: Mr. Gulelat Yohannes
DATE 04/10/ 2024
Systems Analysis and Design An Object
Approach
Oriented
2024
Abstract:
In software engineering, the verification and validation (V&V) of requirements
play a pivotal role in ensuring the correctness and completeness of system
specifications. By formalizing V&V using decomposition and set theory, four
elemental criteria – verifiability, feasibility, necessity, and sufficiency – are
derived, aligning with the INCOSE Guide to Writing Requirements. These criteria
establish parent-child relationships across system architecture levels, from user
needs to component requirements. Implementing these V&V criteria throughout
the requirements development process promises improved first-pass success and
reduced rework by addressing missing, incomplete, incorrect, or unnecessary
requirements.
Simultaneously, requirements analysis strategies form the cornerstone of effective
development practices. This includes structured analysis, cloning, freestyle, and
question and answer approaches. Engineering teams can select a singular strategy
or combine them throughout the program lifecycle, adapting as the system evolves.
As systems transition to the production phase or encounter evolving customer
needs, engineering change proposals may arise, necessitating the addition of new
system elements. Leveraging the cloning strategy, teams utilize existing
specifications or standards to inform the requirements documentation process,
ensuring alignment with established practices and reducing ambiguity.
Through a synergistic approach encompassing rigorous V&V practices and
adaptable analysis strategies, software development teams can navigate the
complexities of requirements management with greater efficiency and precision.
This integration facilitates iterative improvement, fostering a culture of continuous
enhancement and responsiveness to evolving project demands.
Unity University Page 2
Systems Analysis and Design An Object
Approach
Oriented
2024
1) REQUIREMENTS ANALYSIS STRATEGIES
A. Problem Analysis:
Asking users to identify problems and solutions
Improvements from problem analysis tend to be small and incremental
This type of improvements often is very effective at improving a system’s
efficiency or ease of use; however, it provides minor improvements in
business value.
B. Root Cause Analysis
Root cause analysis focuses on problems first rather than
solutions.
Unity University Page 3
Systems Analysis and Design An Object
Approach
Oriented
2024
C. Duration Analysis:
Duration analysis requires a detailed examination of amount of time it takes
to perform each process in the as-is system.
Compare the total time to complete basic steps and the total time for the
overall process – a significant difference indicates that the process is badly
fragmented.
D. Potential solutions:
1. Process integration
2. Parallelization
E. Activity-Based Costing:
Activity-based costing examines the cost of each major process or step in a
business process.
Both direct and indirect costs are considered.
The analysts identify most costly steps and focus improvement efforts on
them.
F. Informal Benchmarking:
Benchmarking refers to studying how other organizations perform a business
process.
Informal benchmarking is common for “customer-facing” processes.
The analysts visit other organizations as customers to watch how the
business process is performed.
G. Outcome Analysis:
Unity University Page 4
Systems Analysis and Design An Object
Approach
Oriented
2024
Outcome analysis focuses on understanding fundamental outcomes that
provide value to customers.
Think what the organization could enable the customer to do
H. Technology Analysis:
Technology analysis involves two steps:
1. The analysts and managers list important and interesting technologies.
2. Then, the group identifies how each and every technology might be applied to
the business and how the business would benefit.
I. Activity Elimination:
The analysts and managers work together to identify.
how the organization could eliminate each and every activity in the business
process and
How the function could operate without it, and what effects are likely to
occur.
J. Comparing Analysis Strategies:
Each of the requirement analysis strategies has its own purpose.
No one strategy is inherently better that the others.
The requirement analysis strategy should be chosen to fit the nature of the
Project.
SUMMARY
Requirements Analysis Strategies are useful for analysts to help the business
users think critically about the new system requirements.
Unity University Page 5
Systems Analysis and Design An Object
Approach
Oriented
2024
2) Requirement Verification and Validation
2.1) what are Requirements Validation & Verification?
A) Validation:
ensures that the software being developed (or changed) will satisfy its
stakeholders
Requirements Validation checks the software requirements specification
against stakeholders goals and requirements
B) Verification:
ensures that each step followed in the process of building the software yields
the right products
Requirements Verification checks the consistency of the software
requirements specification artifacts and other software development products
(design, implementation,) against the specification.
Unity University Page 6
Systems Analysis and Design An Object
Approach
Oriented
2024
C) Requirements V&V Techniques
1.1 Typical Requirements V&V approaches:
Tracing approaches
Prototyping
Testing
User manual writing
Formal validation
Reviews and inspections
Walkthroughs
Formal inspections
Unity University Page 7
Systems Analysis and Design An Object
Approach
Oriented
2024
Checklists
D) Requirements V&V Techniques Tracing approaches
A.Various checks can be done using tracing
Checking that all elicitation notes are covered
Checking goals against tasks, features, requirements
B. Can be done by developing a traceability matrix
C. Ensures that requirements have been taken into to consideration, if not there
should be a reason
D. Ensure that everything in the specification is justified
E) Requirements V&V Techniques Prototyping
A. Prototypes are good way to demonstrate the requirements and help stakeholders
discover problems
help validate requirements
more accessible than specification
B. Different types of prototypes may be used
horizontal, vertical
Evaluative, throwaway...
C. Executable specifications can be used as prototypes.
Unity University Page 8
Systems Analysis and Design An Object
Approach
Oriented
2024
F) Prototyping based
validation steps:
1. Choose prototype testers
2. Develop test scenarios
Careful planning is required to draw up a set of test scenarios which
provide broad coverage of the requirements.
end-users shouldn’t just play around with the system as this
May never exercise critical system features.
3. Execute scenarios
4. Document problems
using a problem reporting tool
G) Requirements V&V Techniques
Testing
1. Each requirement should be testable
It should be possible to define tests to check whether or not a
requirement has been met.
2. Inventing requirements tests is an effective validation technique
missing or ambiguous information in the requirements description
May make it difficult to formulate tests
3. Each functional requirement should have an associated test
Unity University Page 9
Systems Analysis and Design An Object
Approach
Oriented
2024
4. Some software development approaches (e.g. agile methods) start from test
cases (Test Driven Development)
5. Requirements based Test Cases should be written such that they can be traced to
requirements
● have requirement identifiers as part of the test case
description
●Some requirements are harder to validate using
testing
● Some nonfunctional requirements such as reliability,
● Exclusive requirements (say something shouldn't
happen)
H) Requirements V&V Techniques Writing User Manual
1. Forces a detailed look at requirements particularly requirements related to
usability
2. Typical information in a user manual
Description of the functionality and how it is implemented
Which parts of the system have not been implemented
How to get out of trouble
How to install and get started with the system
I) Requirements V&V Techniques Formal V&V
1. Ways to check if a formal specification has certain desirable properties:
completeness
Unity University Page 10
Systems Analysis and Design An Object
Approach
Oriented
2024
consistency
mutual exclusion
particular temporal properties
2. Techniques:
Model checking (for FSMs and temporal logic)
Theorem proving (more general for any formal specification)
3. Formal V&V involves checking all possible execution paths of the
specification
J) Requirements Validation Techniques Formal V&V
1. Model Checking
Automated technique for formally verifying finite state concurrent systems
Used to :
● verify that a model of a system satisfies a specified property
● check correctness of a model
Model: expressed in a formal language with state transition semantics
(possibility of extended states)
Property: expressed in a temporal logic
K) Requirements V&V Techniques Formal V&V
1. Model Checking
model checker verifies M ⇒ P
Unity University Page 11
Systems Analysis and Design An Object
Approach
Oriented
2024
if not a trace of states and transitions leading to the violation of P is
produced
2. Major obstacle is state Explosion
3. Other State Machine based V&V:
Reachability analysis
checks that
4. All states are reachable
5. All events are handled
6. There are no deadlocks
K.1) Other State Machine based V&V
1. Conformance checking
checks conformance between two state machines (one is typically more
concrete/abstract than the other)
Unity University Page 12
Systems Analysis and Design An Object
Approach
Oriented
2024
Equivalence checking
2. between two state machines
3. Different notions of equivalence (e.g. trace, observation, congruence,)
L) Requirements V&V Techniques Reviews
1. A group of people read and analyses the requirements, look for problems, meet
and discuss the problems and agree on actions to address these problems
2. A widely used requirements validation technique
lots of evidence of effectiveness of the technique
3. Can be expensive
careful planning and preparation
preview checking
use of checklists
4. Different types of reviews with varying degree of formality
Reading and signing off: reading the document and signing of to
endorse it
Walkthroughs
5. Informal, often high-level overview.
6. Can be led by author/expert to educate others on his/her work.
Formal inspections
7. Very structured and detailed review, defined roles for participants and
Preparation is needed
Focused inspections
8. Reviewers have roles and each looks only for specific types of errors.
Active reviews
Unity University Page 13
Systems Analysis and Design An Object
Approach
Oriented
2024
10. Reviewer is asked to use the specification
11. The author poses questions for the reviewer to answer that can be
Answered only by reading the document
12. Review process:
13. Plan review
The review team is selected and a time and place for the review
meeting is chosen.
14. Distribute documents
The requirements document is distributed to the review team
members
15. Prepare for review
Individual reviewers read the requirements to find conflicts,
omissions, inconsistencies, deviations from standards and other
problems.
16. Hold review meeting
Individual comments and problems are discussed and a set of
actions to address the problems is agreed.
Unity University Page 14
Systems Analysis and Design An Object
Approach
Oriented
2024
17. Followup actions
The chair of the review checks that the agreed actions have been
carried out.
18. Revise document
The requirements document is revised to reflect the agreed actions.
At this stage, it may be accepted or it may be re-reviewed
19. Reviews should involve a number of stakeholders drawn from different
backgrounds
People from different backgrounds bring different skills and
Knowledge to the review
Stakeholders feel involved in the RE process and develop an
Understanding of the needs of other stakeholders
Review team should always involve at least a domain expert and
An end-user.
Example of problems categorization
Requirements clarification
20. The requirement may be badly expressed or may have accidentally omitted
Information which has been collected during requirements elicitation.
Missing information
21. Some information is missing from the requirements document. It is the
Responsibility of the requirements engineers who are revising the document
To discover this information from system stakeholders.
Requirements conflict
22. There is a significant conflict between requirements. The stakeholders
involved must negotiate to resolve the conflict.
Unity University Page 15
Systems Analysis and Design An Object
Approach
Oriented
2024
Unrealistic requirement
23. The requirement does not appear to be implementable with the technology
Available or given other constraints on the system. Stakeholders must be
Consulted to decide how to make the requirement more realistic.
M) Requirements V&V Techniques Pre-review
checking
1. Reviews are expensive because they involve a number of people spending
times reading and checking the requirements document.
expense can be reduced by using pre-review checking
One person checks the document and looks for straightforward
problems such as missing requirements, lack of conformance to
standards, typographical errors, etc.
Unity University Page 16
Systems Analysis and Design An Object
Approach
Oriented
2024
N) Requirements V&V Techniques Fagan's
Inspection Process
1. Formal and structured inspection process:
Unity University Page 17
Systems Analysis and Design An Object
Approach
Oriented
2024
2. Characterized by rules on who should participate, how many reviewers should
participate and what roles they should play
3 to 5 reviewers
author serves as the presenter of the document
author supervisor do not attend the meeting or get access to the notes
a moderator is responsible for initiating the inspection, leading the meeting
and ensuring issues found are fixed
all reviewers need to prepare themselves using checklists
Unity University Page 18
Systems Analysis and Design An Object
Approach
Oriented
2024
issues are recorded in special forms
3. New inspection if >5% of document need to be reworked
criteria is often made tighter (reinsertion if any document has to be
Reworked because new error may be introduced at correction time)
O) Requirements V&V Techniques Requirements
Review Checklists
1. Essential tool for an effective review process
list common problem area and guide reviewers
2. There are general checklists and checklists for particular modeling and
specification languages
3. Checklists are supposed to developed and maintained
4. Sample of elements in a requirements review checklist
Understandability can readers of the document understand what the
requirements mean?
Redundancy is information unnecessarily repeated in the requirements
document?
Completeness does the checker know of any missing requirements or is
there any information missing from individual requirement descriptions?
Ambiguity are the requirements expressed using terms which are clearly
defined? Could readers from different backgrounds make different
interpretations of the requirements?
Unity University Page 19
Systems Analysis and Design An Object
Approach
Oriented
2024
Consistency do the descriptions of different requirements include
contradictions? Are there contradictions between individual requirements
and overall system requirements?
5. Sample of elements in a requirements review checklist
Organization is the document structured in a sensible way? Are the
descriptions of requirements organized so that related requirements are
grouped?
Conformance to standards does the requirements document and individual
requirements conform to defined standards? Are departures from the
standards, justified?
Traceability are requirements unambiguously identified, include links to
related requirements and to the reasons why these requirements have been
included?
6. Advantages:
effective (even after considering cost)
allow finding sources of errors (not only symptoms)
authors are more attentive when they know their work will be closely
reviewed
7. Encourage them to conform to standards
familiarize large groups
8. Risks
Reviews can be dull and draining (need to be limited in time)
Time consuming and expensive (but usually cheaper than the alternative)
Personality problems
Office politics
Unity University Page 20
Systems Analysis and Design An Object
Approach
Oriented
2024
Summary
The V&V method helps ensure that requirements are clear and doable. It breaks
down the process into smaller parts and checks if each part meets specific criteria
like being understandable, possible to do, necessary, and enough. By following
these steps, teams can avoid mistakes and save time by not having to fix errors
later.
Unity University Page 21
Systems Analysis and Design An Object
Approach
Oriented
2024
When it comes to analyzing requirements, the article suggests using different
methods based on what works best for the project. It could be sticking with one
method or using a mix of them. For example, if there are changes needed in the
project, teams can use a method called cloning to borrow ideas from existing
specifications.
REFRENCE:
Carson, Ronald S. & Licorice, Began (2008). Using Performance-Based Earned
Value for
Measuring Systems Engineering Effectiveness, Proceedings of the International
Council on
Systems Engineering, Utrecht, the Netherlands...
Decamp, C., & Lagarrigue, A. (2007). MV2 Tool Presentation: A Management
Tool for the
Unity University Page 22
Systems Analysis and Design An Object
Approach
Oriented
2024
Validation and Verification of Requirements by Airbus. Proceedings of the
International
Council on Systems Engineering, San Diego, CA, USA.
Elm, J. P. (2008). A Survey of Systems Engineering Effectiveness. Software
Engineering Institute
Report CMU/SEI-2008-SR-034.
Grady, J. O. (2006). System Requirements Analysis. Burlington, MA: Elsevier,
Inc.
INCOSE. (2015). Systems Engineering Handbook: A guide for System Life Cycle
Processes and
Activities, INCOSE-TP-2003-002-04, 4th Edition, 2015.
https://www.researchgate.net/publication/
327073152_Formalizing_Requirements_Verification_and_Validation
Unity University Page 23
