*****  Computer Select, January 1994  : Articles *****

Journal:    UNIX Review  Oct 1993 v11 n10 p51(4)
COPYRIGHT Miller Freeman Inc. 1993
-------------------------------------------------------------------------
Title:     Applying software engineering.
             (Order and Chaos)
Author:    Kehoe, Ray


Abstract:  Many software shops are chaotic and unruly, with programmers
           failing to use well-defined methodologies or working in
           different ways that are incompatible with each other. Software
           engineering can be disciplined through careful specification,
           requirements definition, implementation, testing and
           maintenance. Applying discipline to software development
           usually meets with initial resistance and causes confusion
           before showing benefits. Managers should apply software
           engineering initially only to the first few steps of the
           process, focusing on specification and requirements
           definition. Product specification can be difficult because
           marketing departments do not always know what they need to
           tell engineering departments. Key questions to ask include
           what the product is and what its purpose is, what assumptions
           surround the product, what context the product will exist in
           and what technical constraints and risks apply. The
           requirements-definition phase involves refining the
           capabilities and constraints already discussed and determining
           budgets and schedules.
-------------------------------------------------------------------------
Full Text:

Regardless of the model or methodology used, it is

generally recognized that the software life cycle consists of these
phases: specification, requirements definition, implementation, testing,
and maintenance. Asking the right questions during each phase provides
accurate information for the next phase. The key to good software
engineering is to ask the right questions of the right people at the
right time, and to have the answers reviewed by the right people.

Before software engineering can effectively help the development effort,
the management, marketing, and engineering departments must come to a
common understanding of what the product will be and the costs involved
in creating or enhancing the product. Without a common understanding,
these three departments are likely to work at cross purposes, creating a
negative impact on the product's final quality, cost, and schedule as
well as morale within the company. The opportunity to establish a common
understanding appears primarily in the first two phases of the
software-engineering process (specification and requirements definition).
This article addresses the implementation of these two phases.

Phase One: Product Specification

The purpose of the specification phase is to identify the needs of the
customer and the product features to meet those needs. The marketing
department takes the lead in this effort and is responsible for creating
a Marketing Requirement Document (MRD) or System Specification (SS).

Difficulties arise because marketing doesn't always know what it needs to
tell engineering so that engineering can form a reasonably accurate
estimate of what it needs to do to build and test the product. As a
result, even if a MRD or SS is written, it is not detailed enough, too
detailed, or written in a manner that makes it unapproachable by
engineers.

Actually, the MRD or SS can be a fairly simple and straightforward
document to create and review. Just ask the right questions and state the
answers in a manner that makes them easy to read, understand, and
discuss. The following questions are the ones that should be asked during
this phase.

What is the product and what is its purpose? Marketing needs to state
briefly what the product is and the problem it is meant to solve. This
description will allow the customer, as well as marketing, engineering,
and management, to have a common understanding of what will be built and
why.

What assumptions surround this product? Why does marketing think people
need this product? Why will the company benefit from producing this
product? These assumptions need to be validated by management and
engineering; otherwise, the product will be based on false premises and
most likely will fail.

In what context does this product exist? How does it fit into the system?
Marketing, supported by engineering, needs to identify at a high level
the inputs (data and control), the source of the inputs to the product,
the expected outputs from the product (processed data and control), and
the output's destination.

What do we want this product to do? Having identified the context in
which the product will exist, marketing must now describe the
functionality to be exhibited by the product. Marketing must list the
individual functional capabilities of the product in a clear and concise
manner; otherwise, it runs the risk that engineering will misinterpret
these capabilities, incorrectly define the requirements needed to
implement them, and misjudge the cost in dollars and hours to implement
them.

What are the product's technical constraints? Marketing, supported by
engineering, must identify the timing, sizing, throughput, and
data-retention constraints as well as any industry standards that apply
to this product. If the constraints are not identified during this phase,
then engineering may create a product that is too big, too slow, or fails
to meet standards. When this happens, schedules will slip because of
further changes to the product.

Within what configuration must this product operate? Marketing must
identify the hardware and operating system, third-party software (and
version), and the prior releases of the product with which the new
product must be compatible.

Who is the produet's user? Marketing is closest to the user, so it must
identify the user's level of education, technical background, familiarity
with computers, and working environment. This information will have a
large impact on the sophistication and usability of the product's
interface.

How will the user use this product? Marketing, supported by engineering,
must identify the various tasks to which the user will apply the product,
how often each task will be performed, and the priority of the various
tasks. This information will affect the product's user interface and
reliability, and it will focus the development and testing strategies.

What product documentation should be supplied? Marketing must identify
what customer-related documentation is needed. This allows the
publications department to generate a preliminary cost for these
documents.

What are the technical risks associated with this product? Marketing and
engineering must identify the technical difficulty in developing and
marketing the product. Such things as external dependencies or the level
of certitude concerning the requirements must be identified, evaluated,
and understood so that marketing, engineering, and management can work
together to minimize the risk.

Accurately answering these questions provides many benefits during all
succeeding phases. Answers to these questions lay a strong foundation for
engineering to build upon in the requirements-definition phase. Also,
management obtains the information to make a "go" or "no-go" decision,
and marketing has focused its understanding of the product's market. But
to repeat a point made earlier, the most important benefit is that
marketing, engineering, and management will now have a common
understanding of the product, the customer, the costs, and the risks
involved in creating the product.

Phase Two: Requirements Definition

In this phase, engineering refines the capabilities and constraints
identified in the MRD or SS and decomposes them into implementation
requirements, as described in the Software Requirement Specification
(SRS). In addition, detailed budgets and schedules for subsequent phases
can be determined. Several important questions must be answered during
this phase.

What are the engineering assumptions? Engineering must identify the
assumptions on which it will base its statement of requirements, costs,
and schedules. Examples include the level of engineering talent that the
project will require, or the availability of hardware and software. These
assumptions need to be validated by management and engineering.

What are the implementation requirements? Engineering must refine the
product capabilities identified in the MRD into implementation
requirements. These implementation requirements must include cost
estimates and must be tied to a product capability specified in the MRD
or SS. Pricing the requirements and tracing them back to a marketing
capability will allow business-like decisions concerning which
requirements are implemented and which ones are postponed or dropped due
to cost or schedule.

What are the derived requirements? Engineering must identify derived
requirements that cannot be traced directly to a MRD capability, such as
the need to use a relational database or develop a software timer to
control software interrupts. Some thought must be given to identifying
these requirements so their development or purchase can be included in
the project's budget and schedule.

If the system can be in a logical state, what functions exist within each
state? Certain applications can be in one of several states. For example,
operating systems move a process from one state to another. Communication
protocols are state driven. Word processing software "grays" out certain
selections on menus depending on what logical state the product is in.
Only a subset of functions may be available within any given state.
Engineering, supported by marketing, must identify those requirements
that exist only in some states so that the design and test cases can
reflect this.

How do the technical constraints apply to implementation or derived
requirements? Engineering must identify what technical constraints may
apply to specific requirements. These constraints have an impact on the
design and implementation of the product and the manner in which it is
tested.

What are the user operations? Engineering, supported by marketing, should
refine the user tasks identified in the previous phase into detailed user
operations. This information will form the basis of the user interface
design and test cases.

How are the external interfaces defined? Engineering, supported by
marketing, must define the external interfaces identified in the previous
phase down to their individual components and the range of values for
each component. An example of this would be a high-level data-identified
flow named employee record being decomposed into the individual fields
that make up such a record (name, social security number, grade) and
having each field's size and legitimate values identified.

What are the key algorithms needed by this product? Do we really want
software engineers calculating federal withholding taxes,
missile-navigation algorithms, or the routing of phone calls across the
nation? Engineering, supported by marketing, must work with the
application experts to identify these types of algorithms.

What are the error-handling requirements? Engineering, supported by
marketing, must define what can go wrong with the system and what the
system should do when it enters an error state. This information should
be written down so agreement can exist between the customer and
engineering. In addition, engineering needs this information for its test
plans and documentation.

How will the requirements be tested? Engineering needs to identify how
each requirement will be tested or whether it can be tested. If a
requirement cannot be tested, it needs to be restated so that it can be
tested or the requirement needs to be deleted since it can never be
proven or disproven that it was actually implemented. At this stage, the
manner in which it can be tested, such as demonstration, analysis, or
inspection, should be stated.

The SRS is the most important document produced during the first two
phases. The product's design, test cases, user documentation and all
development costs and schedules will be based on the information found in
this document. The SRS serves as a contract between engineering on one
hand and marketing and management on the other. Any change to this
document will almost automatically cause a change to the schedule and
budget. Most schedule and budget revisions are caused by changes or
additions to product capabilities, interfaces, or configurations.

Applying These Phases

Not every project will need all the preceding questions answered. In such
cases, some of these questions can be deleted. Some questions cannot be
answered completely during the phases described here. This is a
management problem, not an engineering problem. Someone must be assigned
to answer the questions, a date must be given for the answers, and the
organization as a whole must make the conscious decision to assume the
risk involved in forging ahead in the development process without a
complete understanding and agreement.

If you are considering implementing software engineering in your shop,
start with just the two steps outlined here. Avoid long discussions of
design diagrams, analysis methods, and other abstract issues. Try the
most fundamental aspect of quality control: communication among the key
players. Have them all commit to the project they have defined, and in
short order, you'll find that a new discipline has arisen within your
team.

Ray Kehoe has been a software developer and manager in several different
industries. Currently he consults on software engineering and management
issues, lectures at several universities, and coordinates a certiftcate
program in software engineering for the University of California at Santa
Cruz.
-------------------------------------------------------------------------
Topic:     Management of EDP
           Programming Management
           Software Engineering
           Guidelines
           Process Management


Record#:   14 369 226
                              *** End ***
