Enter Keywords:
Home arrow Product Engineering Practices
Product Engineering Practices

Software Requirements Specification Print E-mail
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.
Use Cases Print E-mail
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.
Functional Requirements Print E-mail
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).
Requirements vs. Design Print E-mail
This handout illustrates the differences between needs, requirements and design.

Requirements vs. Design (PDF)
Requirements vs. Design (MS Word)

Design and Programming Tools Print E-mail

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.

Refactoring and Unit Testing Print E-mail
This handout gives examples of refactoring and unit testing in Java.

Refactoring and Unit Testing (PDF)
Refactoring and Unit Testing (MS Word)

Test Plan and Test Cases Print E-mail
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.

Main Menu
Software Project Planning Practices
Review Practices
Product Engineering Practices
For Educators: Lecture Notes and Handouts
Praise for "Applied Software Project Management"
News from O'Reilly
Latest Releases from O'Reilly
Contact Us
Buy the Book
"Applied Software Project Management" © 2005 O'Reilly Media, Inc.
Website © 2006 Stellman & Greene Consulting LLC. Photos by Nisha Sondhe.