Home 
Product Engineering Practices
Product Engineering Practices
|
|
It seems obvious that we need to know what software is supposed to do
before we build it. Nevertheless, many projects are delayed (or fail
completely) because development begins before anyone on the project
team really understands how the software should behave. The solution to
this problem is to take the time to gather and verify the software requirements—documentation
that completely describes the behavior that is required of the
software—before the software is designed, built, and tested. |
|
Read more...
|
|
|
A use case is a description of a specific interaction that a user may
have with the software. Use cases are deceptively simple tools for
describing the behavior of the software. A use case contains a textual
description of all of the ways that the intended users could work with
the software through its interface. Use cases do not describe any
internal workings of the software, nor do they explain how that
software will be implemented. They simply show the steps that the user
follows to use the software to do his work. All of the ways that the
users interact with the software can be described in this manner. |
|
Read more...
|
|
|
Functional requirements define the internal workings of the software:
that is, the calculations,technical details, data manipulation and
processing, and other specific functionality that shows how the use
cases are to be satisfied. It also contains nonfunctional requirements,
which impose constraints on the design or implementation (such as
performance requirements, quality standards, or design constraints). |
|
Read more...
|
|
This handout illustrates the differences between needs, requirements and design.
Requirements vs. Design (PDF)
Requirements vs. Design (MS Word)
|
|
|
There are many tasks over the course of a software project
which can be automated. Unit tests are a good example of automation—before programmers started using
automated unit tests, they had to manually verify each function and user
interface element before delivering a build. By automating unit tests, the
programmers were able to make them much less time-consuming task, and as a
result many more programmers take the time to build unit tests.
But unit tests are not the only manual
programming task that
can be automated. Automation can ensure that the software is built the
same way
each time, that the team sees every change made to the software, and
that the
software is tested and reviewed in the same way every day so that no
defects
slip through or are introduced through human error. A project manager
can help the programmers avoid chronic quality problems by adopting
some of these tools.
|
|
Read more...
|
| |
|
Throughout the entire software project, the team does many things to
find and prevent defects. Once the software has been built, it’s time
to look back and make sure that it meets the requirements. The goal of
software testing is to make sure that the product does what the users
and stakeholders need it to do. Software testers review the final
product to make sure that the initial requirements have been met.
In software testing, quality is defined as “conformance to
requirements.” Every use case, functional requirement, and other
software requirement defines a specific behavior that the software must
exhibit. When the software does not behave the way that the
requirements say it must behave, that is a defect. This means
that software testers are responsible for figuring out whether the
software that was produced by the team behaves in the way that the
requirements it was built from say that it should. |
|
Read more...
|
|
|
