ZeePedia

Requirements Management, Requirements analysis

<< Product-related Problems, Technology-related problems
Requirements Elicitation for Software >>
img
Software Project Management (CS615)
LECTURE # 13
2. Software Development Fundamentals
Technical Fundamentals
2.11
Requirements Management
Preview
Software requirements engineering is a process of discovery, refinement,
modeling and specification. The system requirements and role allocated to
software-initially established by the system engineer-are refined in detail.
Models of the required data information and control flow and operational
behavior are created. Alternative solutions are analyzed and a complete
analysis model is created.
Requirements engineering is the systematic use of proven principles,
techniques, languages, and tools for the cost effective analysis,
documentation, and on-going evolution of user needs and the specification
of the external behavior of a system to satisfy those user needs. Notice that
like all engineering disciplines, requirements engineering is not conducted
in a sporadic random or otherwise haphazard fashion, but instead is the
systematic use of proven approaches.
Both the software engineer and customer take an active role in software
requirements engineering-a set of activities that is often referred to as
analysis. The customer attempts to reformulate a sometimes nebulous
system-level description of data, function and behavior into concrete
detail. The developer acts as interrogator, consultant, problem solver and
negotiator.
The overall role of Software in a larger system is identified during system
engineering. However, it's necessary to take a harder look at software's
role-to understand the specific requirements that must be achieved to build
high-quality software. That's the job of software requirements analysis. To
perform the job properly, you should follow a set of underlying concepts
and principles. Generally, a software engineer performs requirements
analysis However, for complex business applications a 'system analyst'
trained in the business aspects of the application domain may perform the
task. If you don't analyze, it's highly likely that you'll build a very elegant
software solution that solves the wrong problem. The result is wasted time
and money, personal frustration and unhappy customers.
92
img
Software Project Management (CS615)
Data, functional, and behavioral requirements are identified by eliciting
information from the customer. Requirements are refined and analyzed to
assess their clarity, completeness, and consistency.
Requirements analysis
Requirements analysis is a software engineering task that bridges the gap
between system level requirements engineering and software design
(Figure 1). Requirements engineering activities result in the specification
of software's operational characteristics (function, data; and behavior),
indicate software's interface with other system elements, and establish
constraints that software must meet. Requirements analysis allows the
software engineer (sometimes called analyst in this. role) to refine the
software allocation and build models of the data, functional, and
behavioral domains that will be treated by software. Requirements
analysis provides the software designer with a representation of
information, function, and behavior that can be translated to data,
architectural, interface, and component-level designs. Finally, the
requirements specification provides the developer and the customer with
the means to assess quality once software is built.
Figure 1: a bridge between system engineering and software design
System
Engineerin
g
Software
Requirement
s
Software
Analysis
Design
Software requirements analysis may be divided into five areas of effort:
(1) Problem recognition,
(2) Evaluation and synthesis,
(3) Modeling
(4) Specification, and
(5) Review
93
img
Software Project Management (CS615)
Initially, the analyst studies the System Specification (if one exists) and
the Software Project Plan. It is important to understand software in a
system context and to review the software scope that was used to generate
planning estimates. Next, communication for analysis must be established
so that problem recognition is ensured. The goal is recognition of the basic
problem elements as perceived by the customer/users.
Problem evaluation
Problem evaluation and solution synthesis is the next major area of
effort for analysis. The analyst must define all externally observable
data objects, evaluate the flow and content of information, define and
elaborate all software functions, understand software behavior in the
context of events that affect the system, establish system interface
characteristics, and uncover additional design constraints. Each of
these tasks serves to describe the problem so that an overall approach
or solution may be synthesized. For example, an inventory control
system is required for a major supplier of auto parts. The analyst finds
that problems with the current manual system include:
(1) Inability to obtain the status of a component rapidly
(2) Two or three-day turnaround to update a card file
(3) Multiple reorders to the same vendor because there is no way to
associate vendors with components, and so forth.
Once problems have been identified, the analyst determines what
information is to be produced by the new system and what data will be
provided to the system. For instance, is the customer desires a daily
report that indicates what parts have been taken from inventory and
how many similar parts remain. The customer indicates that inventory
clerks will log the identification number of each part as it leaves the
inventory area.
Solution synthesis
Upon evaluating current problems and desired information (input and
output), the analyst begins to synthesize one or more solutions. To
begin, the data objects processing functions and behavior of the system
are defined in detail. Once this information has been established, basic
architectures for implementation are considered.
A client/server approach would seem to be appropriate, but does the
software to support this architecture fall within the scope outlined in
the Software Plan? A database management system would seem to be
required, but is user/customer's need for associativity justified? The
process of evaluation and synthesis continues until both analyst and
94
img
Software Project Management (CS615)
customer feel confident that software can be adequately specified for
subsequent development steps.
Throughout evaluation and solution synthesis, the analyst's primary
focus is on "what, not "how." What data does the system produce and
consume what functions the system must perform. What behaviors do
the system exhibit, what interfaces, are defined and what constraints
apply?
During the evaluation and solution synthesis activity, the analyst
creates models of the system in an effort to better understand data and
control flow, functional processing, operational behavior, and
information content. The model serves as a foundation for software
design and as the basis for the creation of specifications for the
Software. The customer may be unsure of precisely what is required.
The developer may be unsure that a specific approach will properly
accomplish function and performance. For these, and many other
reasons, an alternative approach to requirements analysis, called
Prototyping, may be conducted.
95
Table of Contents:
  1. Introduction & Fundamentals
  2. Goals of Project management
  3. Project Dimensions, Software Development Lifecycle
  4. Cost Management, Project vs. Program Management, Project Success
  5. Project Management’s nine Knowledge Areas
  6. Team leader, Project Organization, Organizational structure
  7. Project Execution Fundamentals Tracking
  8. Organizational Issues and Project Management
  9. Managing Processes: Project Plan, Managing Quality, Project Execution, Project Initiation
  10. Project Execution: Product Implementation, Project Closedown
  11. Problems in Software Projects, Process- related Problems
  12. Product-related Problems, Technology-related problems
  13. Requirements Management, Requirements analysis
  14. Requirements Elicitation for Software
  15. The Software Requirements Specification
  16. Attributes of Software Design, Key Features of Design
  17. Software Configuration Management Vs Software Maintenance
  18. Quality Assurance Management, Quality Factors
  19. Software Quality Assurance Activities
  20. Software Process, PM Process Groups, Links, PM Phase interactions
  21. Initiating Process: Inputs, Outputs, Tools and Techniques
  22. Planning Process Tasks, Executing Process Tasks, Controlling Process Tasks
  23. Project Planning Objectives, Primary Planning Steps
  24. Tools and Techniques for SDP, Outputs from SDP, SDP Execution
  25. PLANNING: Elements of SDP
  26. Life cycle Models: Spiral Model, Statement of Requirement, Data Item Descriptions
  27. Organizational Systems
  28. ORGANIZATIONAL PLANNING, Organizational Management Tools
  29. Estimation - Concepts
  30. Decomposition Techniques, Estimation – Tools
  31. Estimation – Tools
  32. Work Breakdown Structure
  33. WBS- A Mandatory Management Tool
  34. Characteristics of a High-Quality WBS
  35. Work Breakdown Structure (WBS)
  36. WBS- Major Steps, WBS Implementation, high level WBS tasks
  37. Schedule: Scheduling Fundamentals
  38. Scheduling Tools: GANTT CHARTS, PERT, CPM
  39. Risk and Change Management: Risk Management Concepts
  40. Risk & Change Management Concepts
  41. Risk Management Process
  42. Quality Concept, Producing quality software, Quality Control
  43. Managing Tasks in Microsoft Project 2000
  44. Commissioning & Migration