Week 12 Requirements Management PART2

1. Requirements Management PART III

REQUIREMENTS
MANAGEMENT PART
III
DR. CHANDRA REKA

2. OUTLINE

SOFTWARE CRISIS
REQUIREMENT MANAGEMENT SKILLS
RECONCILING DIFFERENCES BETWEEN
STAKEHOLDERS
SOFTWARE CONFIGURATION MANAGEMENT

3. Learning Outcomes

At the end of this lesson, you should be able to:
◦ - Discuss Software Crisis
◦ - Discuss the requirements management
◦ - Discuss the differences between stakeholders
◦ - Elaborate the software configuration management
SWE307
3

4.

◦ CHAOS report indicates only a distinct minority of software projects is
completed on time and under budget
◦ Successful projects are only 16.2%
◦ Challenged projects accounted for 52.7%
◦ Impaired projects accounted for 31.1%

5. SOFTWARE CRISIS

◦ Software Crisis is a term used in computer science for the difficulty of writing useful and efficient
computer programs in the required time
◦ software crisis was due to using same workforce, same methods, same tools even though rapidly
increasing in software demand, complexity of software and software challenges.

6. Software Crisis

◦ Failures attributed to poor
requirements management:
◦ Incorrect definition of
requirements
◦ Poor management throughout
development lifecycle
◦ Effective requirements
management!
◦ The factor most related to
successful projects
◦ Ensures right problem is solved
◦ Ensures right system is built

7. SOLUTION OF SOFTWARE CRISIS

◦ Reduction in software over-budget
◦ The quality of software must be high
◦ Less time needed for software project
◦ Experience working team member on software project
◦ Software must be delivered

8. Reconciling Differences

◦ One of the most important activities in requirements management is consensus building, particularly
when forming or discovering:
◦ ◾ Mission statements
◦ ◾ Goals
◦ ◾ Requirements
◦ ◾ Rankings
◦ But achieving consensus between stakeholder groups is not easy

9.

Global Requirements Management
◦ Bhat et al. (2006) highlighted nine specific problems they observed or experienced. These included: ◾ Conflicting client–
vendor goals
◦ ◾ Low client involvement
◦ ◾ Conflicting requirements engineering approaches (between client and vendor) ◾ Misalignment of client commitment
with project goals
◦ ◾ Disagreements in tool selection
◦ ◾ Communication issues
◦
◾ Disowning responsibility
◦ ◾ Sign-off issues
◦ ◾ Tools misaligned with expectation
◦ Bhat et al. suggest that the following success factors were missing in these cases, based on an analysis of their project
experiences:
◦
◾ Shared goal—that is, a project metaphor
◦ ◾ Shared culture—in the project sense, not in the sociological sense
◦ ◾ Shared process
◦ ◾ Shared responsibility
◦ ◾ Trust

10. Requirements Management

◦ A systematic approach to
◦ Eliciting
◦ Organizing
◦ Documenting
◦ And managing the changing requirements of a
software project

11. Rational Approach to Requirements Management

◦ Rational provides complete solution
to requirements management
◦ Rational Unified Process(RUP)
◦ Recommends specific
requirements management skills
◦ Provides specific guidelines to
effectively implement skills
◦ Tools to automate these skills
◦ RequisitePro, Rose, ClearCase

12. Rational Unified Process (RUP)

◦ Rational Unified Process (RUP) is an agile software development method, in which the life cycle of a
project, or the development of software, is divided into four phases.
◦ Various activities take place during these phases: modelling, analysis and design, implementation,
testing and application.
◦ The process is agile because various components can be adjusted, and phases of the cycle can be
repeated until the software meets requirements and objectives.
https://www.toolshero.com/informationtechnology/rational-unified-process-rup/

13. Rational Unified Process (RUP)

14. Requirements Management in RUP

◦ Requirements
management
skills
implemented in
the requirements
core-workflow
◦ Considered
workflows
Details reding: https://airbrake.io/blog/sdlc/rational-unified-process

15. Requirements Management Skills

◦ Six essential management skills:
Analyze the problem.
Understand the user needs.
Define the system.
Manage the scope of the system.
Refine the system definition
Manage the changing requirements

16. Req mgmt. Skill: 1. Analyze the Problem

◦ Purpose is to:
◦ Gain an agreement on system features and goals
◦ Develop Vision document for the project
◦ The key artifacts produced in the workflow:
◦ Vision document
◦ Requirement management plan for the project
◦ Glossary

17. Divergent Goals problems

◦ The divergent goals antipattern exists when there are those who pull in different directions
◦ ◾ Hidden and personal agendas divergent to the mission of an organization starve resources from
strategically important tasks.
◦ ◾ Organizations become fractured as cliques form to promote their own self-interests.
◦ ◾ Decisions are second-guessed and subject to “review by the replay official” as staff try to
decipher genuine motives for edicts and changes.
◦ ◾ Strategic goals are hard enough to attain when everyone is working toward them, without
complete support they become impossible and introduce risk to the organization

18. Req mgmt. Skill: 2. Understand the User Needs

◦ Purpose is to:
◦ Collect information from the various stakeholders of the project
◦ Use different elicitation techniques to elicit requests
The key artifacts produced in the workflow:
Refined vision document
Initial Use case model
Supplementary specifications
Refined glossary

19. Req mgmt. Skill: 3. Define the System

Purpose is to:
◦ Ensure that all project team members understand
the system
◦ Perform high-level analysis on the results collected in
previous workflows
◦ Formally document results
The key artifacts produced in the workflow:
◦ Refined vision document
◦ Refined use case model
◦ Refined Supplementary specifications
◦ Refined glossary

20. Req mgmt. Skill: 4. Manage the Scope of the System

◦ Purpose is to:
◦ Define the set of requirements to be included in this version of the system
◦ Define a set of architecturally-significant features and uses cases
◦ Define attributes and traceability to help prioritize requirements
◦ The key artifacts produced in the workflow:
◦ Iteration plan
◦ Refined vision document
◦ Refined glossary

21. Req mgmt. Skill: 5. Refine the System Definition

◦ Purpose is to:
◦ Provide a more in-depth understanding of the system’s features
◦ Provide detailed descriptions of use cases
◦ Model and prototype user interfaces
◦ The key artifacts produced in the workflow:
◦ User-interface prototype
◦ Detailed use case model
◦ Revised iteration plan
◦ Refined vision
◦ Refined glossary

22. Req mgmt. Skill: 6. Manage Changing Requirements

◦ Purpose is to:
◦ Control and manage change
◦ Set up appropriate requirements attributes and traceabilities

23. Tool Support - RequisitePro

◦ Easy to use requirements management tool
◦ Leverages the power of database with the freedom of Word
◦ Multi-user support
◦ Provides distributed access to projects via its Web interface
◦ Provides document templates and capability to import existing documents

24. RequisitePro Manages Requirements

◦ Define System – templates, import capability, requirement and document types
◦ Manage scope – Traceability matrix and tree, attribute types
◦ Manage change – Suspect links, group discussions, revision history
Details guide on Requirements Management:
https://l.xmu.edu.my/pluginfile.php/612558/mod_resource/con
tent/1/boulanger2018_Requirements%20management.pdf

25. SOFTWARE CONFIGURATION MANAGEMENT

◦ Configuration management involves the identification, tracking, and control of important artifacts
of the system.
◦ Configuration items relevant to the requirements engineer include the individual requirements,
sources of requirements, stakeholders, and the requirements specification document.
◦ Therefore an important part of requirements management is disciplined configuration
management control processes.

26. SOFTWARE CONFIGURATION MANAGEMENT

an umbrella activity that is applied throughout the software process. Because changes can
occur at any time, SCM activities are developed to
(1) identify change
(2) control change
(3) ensure that change is being properly implemented
(4) report change to others who may have an interest
The primary responsibility is the control of change
26

27. Maintenance is Inevitable

◦ System requirements are likely to change while the system is being developed
because their environment is changing
◦ Systems are tightly coupled to their environment
◦ When a system is installed it changes the environment and that can change the
system requirements
◦ The delivered system may not meet its requirements
◦ Systems must be maintained to remain useful in their environment
27

28. SCM ACTIVITIES

29. ACTIVITIES

1. Version control: This involves keeping track of the multiple versions of system
components and ensuring that changes made to components by different developers do
not interfere with each other.
2. System building: This is the process of assembling program components, data,
and libraries, then compiling and linking these to create an executable system.
3. Change management: This involves keeping track of requests for changes to
delivered software from customers and developers, working out the costs and
impact of making these changes, and deciding if and when the changes should
be implemented.
4. Release management: This involves preparing software for external release and
keeping track of the system versions that have been released for customer use.

30. EXERCISE

change management using an example (any application tool of
01 Elaborate
your choice)
02 What is self documenting?
Post your discussion in the MS Teams
self-documenting refers to a website that exposes the entire process of its creation through public
documentation, and whose public documentation is part of the development process.

31. References

• 1. Davis, Alan, Leffingwell, Dean. Using Requirements Management to Speed Delivery of Higher
Quality Applications. Rational Web Site. On-line at
http://www.rational.com/products/whitepapers.
• 2. Kruchten, Philippe. The Rational Unified Process: An Introduction, Second Edition. Reading
MA: Addison Wesley Longman, October 2000, pp.155-169.
• 3. Leffingwell, Dean. A Field Guide to Effective Requirements Management under SEI’s Capability
Maturity Model. Rational Web Site. On-line at http://www.rational.com/products/whitepapers.

32. References

• 4. Leffingwell, Dean. Managing Software Requirements: A Unified Approach. Reading MA: Addison
Wesley Longman, November 2000.
• 5. Oberg, Roger. Applying Requirements with Use Cases. Rational Web Site. On-line at
http://www.rational.com/products/whitepapers.
• 6. Parackel, Thomas. Managing Requirements in a Development Cycle. IWD Web Site. On-line at
http://www.indiawebdevelopers.com/articles.
• 7. Rational RequisitePro. Rational Web Site. On-line at http://www.rational.com/products/reqpro.
• 8. Royce, Walker. Software Project Management: A Unified Framework. Reading MA: Addison Wesley
Longman, December 1999, pp.118-124.
• https://www.toolshero.com/information-technology/rational-unified-process-rup/