ZeePedia buy college essays online


Software Project Management

<<< Previous The Software Requirements Specification Next >>>
 
img
Software Project Management (CS615)
LECTURE # 15
2. Software Development Fundamentals
Technical Fundamentals
2.11
Requirements Management
The Software Requirements Specification
The Software Requirements Specification is produced at the culmination of the
analysis task, The function and performance allocated to software as part of
system engineering are refined by establishing a complete information
description, a detailed functional description, a representation of system behavior,
an indication of performance requirements and design constraints, appropriate
validation criteria, and other: information pertinent to requirements. The National
Bureau of Standards; IEEE (Standard No. 830-1984), and the U.S. Department of
Defense have all proposed candidate formats for software requirements
specifications (as well as other software engineering documentation).
Mode of specification has a great impact on quality of solution. Forcing SWE to
work with incomplete, inconsistence, or misleading specifications result in
frustration and confusion affecting:
­
Quality
­
Timeliness and
­
Completeness of SW product
·
Principles
i.
Separate functionality from implementation.
ii.
Develop a model of desired behavior of a system that encompasses data and
the functional response of a system to various stimuli from the environment.
iii.
Establish the context in which SW operates by specifying the manner in which
other system components interact with software.
iv.
Define the environment in which system operates and indicate how a highly
inter-wined collection of agents react to stimuli in the environment (changes
to objects) produced by those agents.
v.
Create a cognitive model rather than a design or implementation model.
Cognitive model describes a system as perceived by its user community.
103
img
Software Project Management (CS615)
vi.
Recognize that; "the specifications must be tolerant of incompleteness and
augmentable."
vii.
A specification is always a model ­an abstraction-of some real (or envisioned)
situation that is normally quite complex. Hence it will be incomplete and will exit
at many levels of detail.
i.
Establish the content and structure of a specification in a way that will enable it to
be amenable to change.
·
Representation
i.
Representation format and content should be relevant to the problem. (A
general outline of SRS can be developed).
ii.
Information contained within the specification should be nested.
iii.
It should reveal layers of information so that reader can move to the level
of detail required. Paragraph & diagram number scheme to indicate level.
iv.
Diagrams and other notational forms should be restricted in number and
consistent in use. (Confusing or inconsistent notations, whether graphical
or symbolic degrades understating and foster errors.)
v.
Representation should be revisable.
vi.
The content of specification will change. Ideally, CASE tools should be
available to update all representations that are affected by each change.
The function and performance allocated to software as part of system engineering
are refined by establishing:
1.
A complete information description,
2.
A detailed functional description,
3.
A representation of system behavior,
4.
An indication of performance requirements and design constraints,
5.
Appropriate validation criteria, and other: information pertinent to
requirements.
The Introduction of the software requirements specification states the goals and
objectives of the software, describing it in the context of the computer-based
system; actually, the Introduction may be nothing more than the software scope of
the planning document.
104
img
Software Project Management (CS615)
The Software Requirements Specification is produced at the culmination of the
analysis task. The function and performance allocated to software as part of
system engineering are refined by establishing:
­  A complete information description
­  A detailed functional description
­  A representation of system behavior
­  An indication of performance requirements and design constraints
­  Appropriate validation criteria and other information pertinent to
requirements.
The Information Description provides a detailed description of the problem that
the software must solve. Information content, flow, and structure are documented.
Hardware, software, and human interfaces are described (or external system
elements: and internal software functions.
A description of each function required to solve the problem is presented in the
Functional Description.
A processing narrative is provided for each function:
­ Design constraints are stated and justified
­ Performance characteristics are stated, and
­ One or more diagrams are included to graphically represent the overall
structure of the software and interplay among software functions and other
system elements
The Behavioral Description section of the specification examines the operation of
the software as a consequence of external events and internally generated control
characteristics.
Validation Criteria is probably the most important and, ironically, the most often,
neglected section of the Software Requirements specification.
­ How do we recognize a successful implementation?
­ What classes of tests must be conducted to validate function, performance,
and constraints?
We neglect this section because completing it demands a thorough understanding
of software requirements-something that we often do not have at this stage.
Yet, specification of validation criteria acts as an implicit review of all other
requirements. It is essential that time and attention be given to this section.
Finally, the specification includes a Bibliography and Appendix.
105
img
Software Project Management (CS615)
­ The bibliography contains references to all documents that relate to the
software. These include other software engineering documentation,
technical references, vendor literature, and; standards.
­ The appendix contains information that supplements the specifications.
Tabular data, detailed description of algorithms, charts, graphs and other
material, are presented as appendixes.
In many cases the Software Requirements Specification may be accompanied by
an executable prototype (which in some cases may replace the specification), a
paper prototype or a Preliminary User's Manual. The Preliminary Users Manual
presents the software as a black box: That is, heavy emphasis is placed on user
input and the resultant output. The manual can serve as a valuable tool for
uncovering problems at the human/machine interface.
Review
A review of the Software Requirements Specification (and/or prototype) is
conducted by both the software developer and the customer.
Extreme care should be taken in conducting the review because the specification
forms the foundation of the development phase.
The review is first conducted at a macroscopic level; that is, reviewers attempt to
ensure that the specification is complete, consistent, and accurate when the overall
information, functional, and behavioral domains; are considered. However, to
fully explore each of these domains, the review becomes more detailed,
examining not only broad descriptions but the way in which requirements are
worded. For example, when specifications contain "vague terms" (e.g., some,
sometimes, often, usual ordinarily, most, or mostly), the reviewer should flag the
statements for further clarification.
Once the review is complete, the Software Requirements Specification is "signed-
off by both the customer and the developer. The specification becomes a
"contract" for software development. Requests for changes in requirements after
the specification is finalized will not be eliminated. But the customer should note
that each after- the-fact change is an extension of software scope and therefore
can increase cost, and/or protract the schedule.
Even with the best review procedures in place, a number of common specification
problems persist. The specification is difficult to "test" in any meaningful way,
and therefore inconsistency or omissions may pass unnoticed. During the review,
changes to the specification may be recommended. It can be extremely difficult to
assess the global impact of a change; that is, how a change in one function affects
requirements for other functions. Modem software engineering environments
incorporate CASE tools that have been developed to help solve these problems.
106
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