A software requirements specification is written to give the company that’s paying for the project, the people who will use the system, and the developers who will be writing code a clear shared picture of what an application is supposed to do.
photo credit: Understanding via photopin (license)
Because this can be a time-consuming task, companies are tempted to think they’re saving money by skipping the 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.
If the software you need includes more than one module or you’re overwhelmed at the idea of defining all the requirements up front, break the project into smaller pieces. You can define the requirements for phase 1, and while it’s being coded, you can start on requirements for phase 2.
Whether you’re partnering with an outside firm or relying on your internal team, the following steps are critical to creating an understandable and usable software requirements specification.
- 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 are not interchangeable because they’re part of the language and culture of the business.
- Draw pictures. Many ambiguities are eliminated with pictures. One of the best ways to ensure the company and the software developers have a shared understanding of requirements is to 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 are responsible for the work. The discussion should include lots of questions, and the requirements analyst should do more listening than talking. This leads to the next step . . .
- Listen to the people responsible for the business process. The may be the most important thing the person extracting the requirements can do, but it’s also the one most often ignored: LISTEN. The requirements analyst should do more listening than talking.
- Invest enough time. A good specification includes a lot of information, and it takes a significant investment in time to create it. How much time? It depends on many factors including the complexity of the system and the experience of the subject matter experts and requirements analyst, but a small application with no more than six pages/screens could require 8 hours or more.
- Don’t assume a specification is set in stone. No matter how well you define requirements, how clear the process is, and how accurate the screen mockups look, when people actually begin to use a system, they will come up with new ideas or find that even though it works as designed, it’s not exactly what’s required. Changes to requirements mean updates to the system specification, because a specification is “final” only when the new system is working in production. Note: this is a very good reason to break a big system into smaller, manageable pieces. If you include one typical screen in Phase 1, you can see how a mockup translates into a working page, and you can incorporate modifications to Phase 1 into the next phases. This iterative approach is a great way to minimize surprises at the end of a project.
Save time and money with a good specification
A high quality, accurate specification saves time and money because it eliminates costly rework, and it improves satisfaction because you and your developers have a shared understanding of what’s required.
Following these steps doesn’t guarantee you’ll get a requirements document that communicates clearly – that depends in large part on the skills of the people involved. But ignoring these steps increases the probability that your new software will take longer than expected, cost more than planned, and fail to meet your expectations and business needs.
For a more thorough look at capturing Software Requirements, download our FREE white Paper here!
White paper: 7 Critical Steps for Software Requirements
For more than 25 years, DragonPoint has worked with clients to define requirements and create high quality software requirements documents. Call today for expert advice on defining your software system requirements – 321-631-0657.
