Successful software development projects may be elusive, but they are possible if you follow these consistent, proven steps.
- Requirements capture (Interviews and analysis)
- Design
- Programming
- Testing
- Beta software installation, customer beta testing, and feedback
- Final changes, installation of final software, and ongoing support
Step 1: Requirements Capture for Software Development
The first step, requirements capture, results in a specification that is written to give the company that’s paying for the project a clear picture of the deliverables. It also provides the people who will use the system and the developers who will be writing code a shared understanding of what an application is supposed to do. In the past, people expected to define all requirements for a new application up front. This led to delays and disappointment. Now we create a high level picture of the business goals for the new system and then break the development project into smaller pieces, called phases or sprints. Each sprint moves the project towards the high level vision. It will have detailed requirements and can build on lessons learned in earlier sprints. As the development team is coding a sprint, the business and software project managers will be working on requirements for the next deliverable. Companies may be tempted to think they’re saving money by skipping documentation of requirements. Don’t make this mistake! Defining what you need before writing code is the best way to meet your business objectives and keep a software project in budget and on time.How to Capture Great Requirements
Create understandable, usable requirements for your software development project by following these steps.- Understand the business process. Before you can write requirements, you must understand the specific way the business works. Include a description of the business process in the specification. Words are good, and pictures are better.
- Speak the language. A good specification is written in the company’s business language. Although certain words may seem to be synonyms, company-specific terms may not be interchangeable.
- Draw pictures. Many ambiguities are eliminated with pictures. Good requirements include screen mockups.
- Talk to the people responsible for the work. The only way to figure out what a system needs to do is to talk to the people who do the work. The discussion should include lots of questions. The requirements analyst should do more listening than talking.
- Listen to the people responsible for the business process. The may be the most important thing the person documenting requirements can do. It’s also the one most often ignored.
- Invest enough time. A good specification includes a lot of information, and it takes time to create it. How much time? It depends on system complexity, the number of subject matter experts involved, and the experience of the requirements analyst.
- Don’t assume a specification is set in stone. No matter how well you define requirements, when people start testing the system, they will ask for changes. Even if the system complies with the specification, it may not be what the business needs. Plan for changes and document them.