Author: Adriana Beal
If you are a BA working on the IT space, you may be responsible for creating multiple deliverables, many of them intermediate documents such as meeting minutes and as-is/to be business models. You may also be in charge of producing important and high-visibility requirements specifications such as a Vision document describing the application in general terms (including, for example, descriptions of the target market, system users, and the application features), or Business Requirements Document (BRD), describing, at a high level of abstraction, the business needs.
Regardless of how many artifacts you produce in a project, unless you are working on a pure agile environment, the Software Requirements Specification (SRS, sometimes called functional specification, product specification, system specification, or requirements document) will be the most valuable document you will produce during the course of many of your projects. Practicing and improving this skill is something I help analysts do in my course Crafting Better Requirements. What follows is a synopsis of what a software requirements specification is and why it’s a valuable skill.
What is a Software Requirements Specification?
As the name says, the SRS is the specification for a particular software product (or for a specific release, module or component of such product). A Software Requirements Specification must describe all the capabilities a product must have in order to fulfill the business, stakeholder and user needs. It defines the inputs, outputs, functions, and attributes of the system, as well as the attributes of the system environment. According to the IEEE Guide to Software Requirements Specifications, a good software requirements specification leaves out design, verification, and project management details (except for required design constraints), in order to provide the design and development team with maximum flexibility to arrive at the best technical solution that can fulfill the stated needs.
What is the Software Requirements Specification used for?
The Software Requirements Specification is such an important piece of software documentation that it is sometimes produced even after the software product has been designed or developed, to serve as a reference for testing and to address the needs of the operations and maintenance teams.
Besides establishing a clear agreement between supplier and customer on what the completed software must do, a Software Requirement Specification provides crucial information that the Quality Assurance team needs to create test plans that will verify whether the system is indeed fit for purpose. It also offers valuable information for the operations and maintenance teams–for example, an indication of when a software component may be retired because it only supported a temporary need, or which modules or functions of the system are particularly critical for the business, and consequently must be monitored and protected against failure to prevent financial loss or other negative impacts.
A Specification is Not Supposed to Replace Conversations
Clearly, even the finest Software Requirements Specification document will never replace interpersonal discussions that will need to happen throughout the project. It is virtually impossible to discover–and document–every single fragment of information that feeds into software development upfront. A considerable part of the job of an IT analyst is to keep the lines of communication open between the technical and business teams, so that issues that may surface during the project, trade-offs that must be discussed, and requirements details that may have been overlooked can be addressed in a timely and effective manner.
Anyone in IT Will Be Valued for SRS-Writing Skills
In “Testing SAP R/3: a manager’s step-by-step guide”, authors Jose Fajardo and Elfriede Dustin define quality in the context of a software product as:
a system that performs as expected, making available the required system features in a consistent fashion, demonstrating high availability under any type of constraint (i.e., stress, concurrency, security breach, etc.); thus, consistently meeting the user’s expectations and satisfying the system’s user needs can be considered to be high quality.
Undoubtedly, a software product will have a much higher probability to meet users and business expectations if there is a solid reference from which the development team can work and which addresses all relevant aspects of the solution, from the sources of inputs, to performance and external interface requirements. Analysts with the ability to document functional and non-functional requirements that carefully trace back to business requirements and provide a solid foundation for the design and development team to build a solution that achieves the organization’s goals are hard to find, and such skills generate career progression opportunities for analysts who demonstrate talent in this area.
Even when you progress in your career to a position in which is no longer your responsibility to write requirements specifications, your ability to inspect requirements documents to determine their quality will be instrumental for ensuring that the development team has the appropriate input for their work.
If you are interested in developing skills in this area, a good starting point is to dissect Software Requirements Specifications written by talented authors such as Karl Wiegers, read high quality books such as Software Requirements, Third Edition (Pro-Best Practices)
, keep valuable references to consult during your projects, such as The Software Requirements Memory Jogger: A Pocket Guide to Help Software And Business Teams Develop And Manage Requirements (Memory Jogger)
, and most importantly, practice, practice, practice.
As well put by Karl Wiegers in his book More About Software Requirements: Thorny Issues and Practical Advice,
You won’t learn how to write good requirements from reading a book on software requirements engineering or a book on technical writing. You need practice. Write requirements to the best of your ability, and then enlist some of your colleagues to review them. Constructive feedback from reviewers can help anyone become a better writer. In fact, it’s essential. Requirements quality is in the eye of the reader of the requirements, not the author. No matter how fine the author thinks the requirements are, the ultimate arbiters are those who must base their own work on those requirements.
Pingback: What Goes Into a Functional Specification? | Learn Project Management
Would you go over technical with user in a requirments meeting. Such as if there were additional requirments pertaining to a technical implementation of updating mail server, changind AD roles/groups retrieved etc
I would think this would be overkill but at the same time would not want them to later say..we were not told about the new server migrations.
Pingback: software requirements document - UTILITY DOCUMENT – UTILITY DOCUMENT
Thank you for leaving your comment, Deb. I’m glad you are finding the resources available here at Bridging the Gap useful for your project. Good luck with the interface requirements you are writing!
Hi Adriana,
This website brought useful insight to an SRS document that I am working on at this moment. Although it’s not software but more of an interface, I agree that this document is the most valuable document for the project.
Thank you!