REQUIREMENTS ENGINEERING
JIMMA UNIVERSITY
JIMMA INSTITUTE OF TECHNOLOGY
FACULTY OF COMPUTING AND INFORMATICS
CHAPTER EIGHT
REQUIREMENT ENGINEERING BEST PRACTICES AND
TOOLS
Topics we will cover
2
Requirement engineering emerging trends
Best practices of requirement engineering
Requirement engineering tools
Requirement Engineering Emerging trends
3
Globalization
Scale
Dynamic
Requirement Reuse
Requirement Engineering Emerging
trends
4
Discussion
Discuss
Globalization
Scale
Dynamic
Requirement Reuse
…..in terms of Software Engineering
Globalization
5
Team members located in separate geographical
workspace.
Different culture and skills.
The distributed requirements needs:
Efforts to be gathered and managed.
Communicating these requirements among various
distributed parties.
Downstream activities such as design, implementation
and testing requires new RE methodologies to support
them.
Scale
6
Requirements from large scale systems involve a
considerable flow of requirements that need to be carefully
managed and evaluated.
Large scale systems characterized By:
Number of requirements
Number of people employing the system for different
purpose
Amount of requirements stored, accessed, manipulated,
and refined.
Number of connections and interdependencies among
software components.
Dynamic
7
Requirements Engineering is concerned with static
elicitation, representation, and analysis of
requirements.
Advances in technologies and systems that are highly
adaptive and dynamic with high rate of change.
Requirements Reuse
8
The reuse of existing and past requirements artifacts
for future usage is a common trend nowadays.
For an artifact to be reused it should have a standard
pattern such as context, domain, problem, properties
and consequences.
Best Practices of Requirement
9
Engineering
The result is software
that is Performance
On Time Engineer
On Budget Analyst
Meets/Exceeds Users
Needs
Project
Develop Iteratively
Manager
Developer
Use Model
Manage Verify
Requirements
Component
Architectures
Visually
Quality Tester
Control Changes Release
Engineer
Iterative Development
10
Iteration 1 Iteration 2 Iteration 3
Earliest iterations address greatest risks
• Each iteration produces an executable release
• Each iteration includes integration, test, and assessment!
• Objective Milestones: short-term focus; short term successes!
Requirement Engineering Emerging
trends
11
Discussion
Discuss the characterstics of iterartive development?
Iterative Development Characteristics
► Critical risks are resolved before making large investments
► Initial iterations enable early user feedback
Easy to resolve problems early.
Encourages user feedback in meaningful ways
► Testing and integration are continuous – assures
successful integration (parts all fit)
Continuous testing.
► Objective milestones provide short-term focus
► Progress measured by assessing implementations
► Partial implementations can be deployed
Waterfall method – no delivery
Incremental development? May be some great values
in delivering key parts of application. Critical
components delivered first?
► No big-bang approach!
12
Problems Addressed by Iterative Development
Root Causes Solutions
Insufficient requirements Enables and encourages user
feedback
Ambiguous
Serious misunderstandings evident
requirements
early in the life cycle
Brittle architectures
Overwhelming Development focuses on critical
complexity issues – break it down!
Subjective assessment Objective assessment thru testing
Undetected and assessment
inconsistencies
Inconsistencies detected early
Poor testing
Waterfall development Testing starts earlier – continuous!
Uncontrolled change Risks identified and addressed
Insufficient automation early - via planned iterations!
13
Control Changes
14
►Consider: we often have:
Multiple developers
Multiple teams
Multiple sites All at the same time!
Multiple iterations
Multiple releases
Multiple projects
Multiple platforms
May have multiple developers organized into different teams at multiple sites all
working
together on multiple iterations, releases, products, and platforms
(mostly based on the software architecture)
Without explicit control, parallel development leads to chaos!!!!
Problems Addressed by Controlling Changes
Root Causes Solutions
16
Insufficient Requirements change; workflow is
defined and repeatable
requirements
Ambiguous Change requests facilitate clear
communications
requirements
Brittle architectures
Isolated workspaces reduce
Overwhelming interference from parallel work
complexity Change rate statistics are good
metrics for objectively assessing
Subjective assessment project status
Undetected Workspaces contain all artifacts,
inconsistencies facilitating consistency
Poor testing Change propagation is controlled
Waterfall development Changes maintained in a robust,
customizable system
Uncontrolled change
Insufficient automation
Problems Addressed by Verifying Quality
Root Causes Solutions
17
Insufficient requirements Testing provides objective
Ambiguous communications project status assessment
Brittle architectures Objective assessment exposes
Overwhelming complexity inconsistencies early
Subjective assessment (continuous integration
Undetected helps!)
inconsistencies
Testing and verification are
focused on high risk areas
Poor testing
Waterfall development Defects are found earlier and
Uncontrolled change are less expensive to fix
(because ‘testing’ is
distributed…
Insufficient automation
Automated testing tools
provide testing for reliability,
Requirement engineering and management
tools
18
Browse for requirement tools
https://www.guru99.com/requirement-management-tools.html
Key Points
19
Requirement engineering emerging trends
Best practices of requirement engineering
Requirement engineering and management tools
Any Question?
20
