Page 233 - DCAP405_SOFTWARE_ENGINEERING

Software Engineering

Notes A number of quality indicators have been developed which can be used to relate the quality of
software requirements specification to other project variables such as cost, acceptance,
performance, schedule, reproducibility, etc. Quality indicators for individual software
requirements specification statements include imperatives, directives, weak phrases, options,
and continuances. Indicators for the entire software requirements specification document include
size, readability, specification, depth, and text structure.

Self Assessment

Fill in the blanks:

3. Energy should be directed towards ensuring that the final system or product conforms to
client needs rather than attempting to mold user expectations to fit the………………………..
4. Requirements analysis is a …………………… that demands a combination of hardware,
software and human factors engineering expertise as well as skills in dealing with people.
5. A …………………….. requirements analysis is needed to ensure rapid project delivery
and optimal return on information management investment.

6. …………………….. or methods which are poorly supported by training and tools may not
achieve widespread acceptance even if they are suited to particular types of problems.
7. The document lists the system requirements along with …………………… information.

8. Organizations can also use a software requirements specification document to develop
their own …………………and……………………….. plans more productively.
9. ……………………….. has a large number of requirements, and the emphasis is shared.

13.3 Rules-of-Thumb Analysis

Use the Rules-of-Thumb Analysis window to examine specific trace data in the Performance
Warehouse data tables of the performance database using the selected rule of thumb or all rules
of thumb in the selected cluster, and to view the analysis result.
1. The model should focus on requirements that are visible within the problem or business
domain.
The level of abstraction should be relatively high.
2. Each element of the analysis model should
add to an overall understanding of software requirements

provide insight into the
information domain
function of the system

behavior of the system
3. Delay consideration of infrastructure and other non-functional models until design.
4. Minimize coupling throughout the system.
5. Be certain that the analysis model provides value to all stakeholders.
6. Keep the model as simple as it can be.

226 LOVELY PROFESSIONAL UNIVERSITY