Page 92 - DCAP405_SOFTWARE_ENGINEERING

Unit 6: Requirement Engineering

Notes
Did u know? What is the exact meaning of software requirement engineering?

Software requirements engineering is the process of determining what is to be produced
in a software system. In developing a complex software system, the requirements
engineering process has the widely recognized goal of determining the needs for, and the
intended external behavior, of a system design.

6.2 A Brigade of Design & Construction

The final goal of any engineering activity is to create some kind of documentation. When ea
design effort is complete, the design documentation is given to the manufacturing team. This is
a different set of people with a different set of skills from those of the design team. If the design
documents truly represent a complete design, the manufacturing team can proceed to build the
product. In fact, they can proceed to build much of the product without further assistance from
the designers. After reviewing the software development life cycle today, it appears that the
only software documentation that actually seems to satisfy the criteria of an engineering design
are the source code listings.
Software runs on computers. It is a sequence of ones and zeros. Software is not a program listing.
A program listing is a document that represents a software design. Compilers, linkers, and
interpreters actually build (manufacture) software. Software is very cheap to build. You just
press a button. Software is expensive to design because it is complicated and all phases of the
development cycle are part of the design process. Programming is a design activity; a good
software design process recognizes this and does not hesitate to code when coding makes sense.
Coding actually makes sense more often than believed. Often the process of rendering the
design in code will reveal oversights and the need for more design effort. The earlier this
happens, the better. Testing and debugging are design activities – they are the equivalents of
design validation and refinement in other engineering disciplines. They can not be short changed.
Formal validation methods are not of much use because it is cheaper to build software and test
it than to prove it.
Think about it. When you are programming, you are doing detailed design. The manufacturing
team for software is your compiler or interpreter. The source is the only complete specification
of what the software will do.
Whenever objects are created for people to use, design is pervasive. Design may be done
methodically or offhandedly, consciously or accidentally. But when people create software – or
any other product – decisions are made and objects are constructed that carry with them an
intention of what those objects will do and how they will be perceived and used.
The education of computer professionals has often concentrated on the understanding of
computational mechanisms, and on engineering methods that are intended to ensure that the
mechanisms behave as the programmer intends. The focus is on the objects being designed: the
hardware and software. The primary concern is to implement a specified functionality efficiently.
When software engineers or programmers say that a piece of software works, they typically
mean that it is robust, is reliable, and meets its functional specification. These concerns are
indeed important. Any designer who ignores them does so at the risk of disaster.
But this inward-looking perspective, with its focus on function and construction, is one-sided.
To design software that really works, we need to move from a constructor’s-eye view to a
designer’s-eye view, taking the system, the users, and the context all together as a starting point.

LOVELY PROFESSIONAL UNIVERSITY 85