What are software requirements specification (SRS)?
Software requirements specification capture system behavior as opposed to non-functional requirements specifications which define attributes as not behavior.
In product development, it is important to understand the difference between the baseline functionality necessary for any system to compete in that product domain, and features that make the system different from their competitor’s products.
Some strategies have important implications for software architecture. Specifically, it is not just the Software requirements specifications of the initial release that must be supported in the architecture. The Software requirements specifications of initial products need to be explicitly taken into consideration.
1. Software requirements specifications and Use Cases
2. Requirements and Specifications
3. Examples of Software Requirements and Specifications
4. Benefits of a good Software Requirement Specification
5. Getting Strated: Write the Software Requirement Specification
6. Difference between a System Specification and a Software Specification?
Here is the difference between software requirement specification and technical specification.
1. A software requirement specification describes how a product will work entirely from the user’s (or customer’s) perspective. It should care less about implementation. (e.g. the ‘what’ v. the ‘how’)
2. A technical specification describes the internal implementation of the software. It talks about data structures, relational database models, choice of programming protocols, and environmental properties.
-Use Cases
The use case tells the story showing the end-to-end scenario. To further define, a use case defines a goal-oriented set of interactions between external actors and the system under consideration. Actors are parties outside the system that interact with the system. A primary actor has the goal requiring the assistance of the system. A secondary actor is one from which the system needs assistance.
Generally, use case steps are written in an easy-to-understand structured story using the verbage of the domain. This is engaging for users who can easily follow and validate the use cases, and the accessibility encourages users to be actively involved in defining the Software requirements specifications.
-Software Requirements and Specifications
a-The importance of Software Requirements and Specifications
A key benefit of developing a software requirement specification is in streamlining the development process. The developer working from the software requirement specification has, ideally, all of their questions answered about the application and can start to develop. Since this is a functional specfication that was client approved, they are building nothing less than what the customer wants. There should be nothing left to guess or interpret when the functional spec is completed. This is the brilliance of the software requirement specification.
b-Requirements Define Critical Objectives
A software requirement specification is an objective that must be met. The customer or product team define most software requirements in functional terms, leaving design and implementation details to the developers. They may specify price, performance, and reliability objectives in fine detail, along with some aspects of the user interface.
Project requirements provide an obvious tool for evaluating the quality of a project, because a final review should examine whether each requirement has been met. However, it’s often never quite that simple. Requirements tend to change through the course of a project, with the result that the product as delivered may not stick to the available Software requirements specifications — this is a disturbing part of the quality assurance process. Moreover, meeting all of the requirements doesn’t ensure a quality product, rather the requirements may not have been defined with an eye towards the quality of the end-user’s experience. A project’s Software requirements specifications are more useful for determining the product’s quality.
c-Specifications Define How to Meet The Objectives
A software requirement specification document describes how something is supposed to be done. A specifications document may list out all of the possible error states for a certain form, along with all of the error messages that should be displayed. The specifications may also describe the steps of any functional interaction, and the order in which they should be followed by the user. A requirements document, on the other hand, would state that the software must handle error states reasonably and effectively, and provide explicit feedback to the users. The specifications show how to meet this requirement.
Specifications may take several forms. They can be a straightforward listing of functional attributes, they can be diagrams or schematics of functional relationships or flow logic, or they can occupy some middle ground. Software requirements specifications can also be in the form of prototypes, mockups, and models.Project specifications are much more important for determining the quality of the product. Every rule and functional relationship provides a test point.
d-Who should be writing Software requirements specifications
The software requirement specification should be written by someone who is not involved in any other aspect of the project. You will want someone who is very familiar with GUI issues and web design, familiar enough with technology to know its limitations and capabilities, and someone who is a very skilled and a good writer. While writing a spec, you will spend a great deal of time imagining how a user might use a certain feature and how they may navigate their way through the software. The functional spec writer’s main concern is marrying the user-experience with the various business logic’s requirements of the project.
-Examples of Software Requirements and Specifications
a-User Requirements
User requirements typically describe the needs, goals, and tasks of the user. It is encouraged that any user requirements document define and describe the end-user, and that any measurements of quality or success be taken with respect to that end-user.
User requirements are usually defined after the completion of task analysis, the examination of the tasks and goals of the end-user.
b-System Requirements
System requirements has two meanings. First, it can refer to the software requirements that describe the capabilities of the system with which the product will function. For example, the web site may need to run on an application server and be clustered. Second, it can refer to the requirements that describe the product itself, with the meaning that the product is a system.
There are two categories of system requirements. Software requirements specifications specify what the system must do. User requirements specify the acceptable level of user performance and satisfaction with the system. For this later definition, it is preferred to use the more general term “requirements and specifications” over the more boring “system requirements”.
c-Software requirements specifications
Software requirements specifications describe what the software or web site should do by defining functions and high-level logic. If the user requirements are written for the requestor and not the end-user, the user requirements are combined with the Software requirements specifications.
d-Software requirements specifications
Functional specifications describe the necessary functions at the implementation level. These specifications are typically used to build the system exclusive of the GUI.
With respect to a web site, a unit is the design for a specific page or category of page, and the software requirement specification would detail the functional elements of that page or page type. For example, the design for the page may require the following functions: shopping cart page, opt-out email section, context-sensitive navigation elements. These aren’t GUI issues so much as they are “functionality” issues. A component is a set of page states or closely related forms of a page. For example, a component might include a submission page, and the acknowledgement page.
e-Technical Specifications
Technical specifications are typically written the by developers and architects, and describe how they will implement the project. The developers work from the Software requirements specifications, and translate the functionality into their actual coding implementation and methodologies.
f-Important Appendicies
Open Issues—-It’s acceptable for the first version of the software requirement specification to leave open issues. By the time the programmers start the dev process, all issues need to be resolved.
Side notes—-While you’re writing your software requirement specification, remember your various audiences: programmers, testers, marketing, tech writers, etc. As you write the specification you may think of useful factoids that will be helpful to just one of those groups.
Functional Specifications Need To Stay Current- -Some programming teams adopt a “waterfall” mentality: we will design the program all at once, write a software requirement specification, print it, and hand it off to engineering and be done.
Getting Started: Write the Software Requirement Specification
This is the most challenging task of the whole process. You’ve asked the questions, done the preliminary work, made a few mockups, and now it’s just you with a blank document and a head full of ideas. Hopefully though, it’s not totally blank. Throughout the initial steps, you’ve ideally been developing a working outline, and maybe even started writing a few sections as they bubble up. Below are a few tips for writing your software requirement specification:
Cover everything
By this, I mean make sure you’ve written about every single interaction point that exists in the product or application. Don’t leave anything to guess or assume. It’s quite likely that you’ll come to a point where you believe you have covered everything, only to find you have left out something very obvious.
Use lots of screen shots
It’s usually helpful to slice up your mockups and insert screenshots of the individual elements you may be writing about. Functional specfication docs are boring, and having visuals are invaluable. A picture is worth a thousand words, don’t forget it.
Write concisely, correctly, and consistently
An economy of words will be appreciated by those who have to read your functional spec and make sense of it all. Additionally, try and break things out into logical componentsas much as possible. By writing correctly and consistently, make sure you’re using proper grammar and consistent terms.
Use the tools and format most comfortable for you
As a spec writer (software requirement specification writer), you still have quite a few decisions make. What tools do you use? What format? What sort of style should you adopt? Also, you need to take into account how your software specficiation documents will be used: will they need to be online, will they frequently be merged with other documents.
Edit and ReWrite
Rewriting and editing are, literally, half the battle. When setting the timeline for your completion of the software requirement specification, always try to add a week more than you originally anticipated. What typically occurs is that something always comes up during the editing process. Change is the nature of the business and it’s reflected in a software requirement specification. It is important that the software requirement specification is clean, but not perfect. Ideally, no spelling errors, no grammatical errors, no logic errors, and no mock up errors either. Why not perfect? Time is of the essence. It’s better to get ‘good’ software released to get early feedback and make the necessary changes, than ‘great’ software out two weeks later. Many professionals will disagree on this point because their trained for perfection, but what they don’t often realize is that markets and business change beneath their feet.
Check your table of contents
1) Make sure your table of contents correlates exactly with what’s in your document. Edit from beginning to end at least three times after you think it is done Three times seems to usually do the trick…sometimes more is required, but never less. The first pass usually involves a lot of rewriting and renumbering, while the second pass is typically much lighter and may catch some of the obvious things you missed the first time. By the third time, you should be merely polishing and fixing very small details.
2) Have someone proofread your functional spec for you:
This is optional, but I always find that it helps a great deal to have someone else read it over for you (especially if that person has a strong command of the written word).
3) Review: Whether you’re writing a software requirement specification for your company or for a client, you’re going to have a series of people reviewing your functional spec to make sure they understand what’s going to be built. Expect changes and be prepared to give reasons for why everything is written as it is. By the time you take your functional spec to any customers, it should be as close to perfect as possible. Part of the review process is working with your customers to come up with the best solution. If they feel the application will not meet their needs as specified, then find out why and offer solutions as to what can be done to meet their needs. After the review, take your notes back to the computer and make your changes while they’re still fresh in your mind. Be sure to change your mockups and all related text, double check to make sure your changes don’t affect other functionality, and then double check your table of contents. Prepare the software requirement specification for another review. Have everybody signoff on it once a consensus is reached
Discover more from CODE t!ps
Subscribe to get the latest posts sent to your email.