Software requirements specification |
|
Article Purpose
The purpose of this article is to present the concept of the Software Requirements Specification (SRS) and to discuss some of the issues associated with writing the SRS.
|
|
Business requirements versus Software Requirements Specification
Following the previous article on business processing requirements this article introduces the concept of a specification, in that it places a broad definition of specification alongside the already defined notion of requirements. The discussion is scoped by the commercial data processing model, although both manual and automated processes could form the solution or satisfaction of the requirements. It is recommended that the Business requirements article be read first in order to place this article in the overall context of software process improvement frameworks such as CMMi.
In general the term specification is distinct from the term requirements in that the requirements speak to the end user (or customer) while the specification, that satisfies the requirements is directed at the engineer, workflow designer or any other person that is going to produce a solution or component of the solution.
This distinction, of requirement versus specification, is easier to understand in traditional engineering projects. For example a requirement for a motor vehicle could be that the door should be easy to open for the average driver but should still be able to withstand a 30 mph side impact without completely breaking. The specification for this requirement would be something like the door needs a maximum force of 10LBS to open and close and should be able to withstand an impact of 500LBS per square inch. Although the example is simplistic it conveys the idea that the specification is something that is measurable and targeted at the engineer.
In both cases, in the motor vehicle example, the requirements and the specification still refer to What is required (specified) as opposed to How it is produced. If we state anything regarding the production (or satisfaction on the specification) we are introducing a constraint. In the motor vehicle example we may decide that we should only use a certain alloy and if this is present in the specification it needs to be listed as a constraint.
|
|
Commercial data processing
In terms of commercial data processing systems the difference between requirements and specification is small when we are dealing with manual systems (as opposed to software which will be discussed later). Let’s say we have a commercial loan operation some 100 years ago. One of the processing requirements would be that access to the money would be given to the customer on a specified date and time (as per the agreement) following the signing of the loan agreement. Now consider I am writing a specification for a manual process that satisfies this requirement. If we are to keep to an expression of What rather than How in the specification, it is difficult. The problem here is that there is no engineer involved and both requirements and specification, for a process, are written in words that a user (or non technical person) can understand. If we specify a workflow, i.e. Go to the bank, arrange to give the customer the cash in the bank etc. we are moving into How the requirement (or specification) is achieved and away from the distinction and definitions we have set for the engineering terms requirements and specification.
Having looked at a broad definition of specification, we now look at the issues with using automation (software) in our processing solution.
|
|
Issues with the software specification
The software specification or the Software Requirements Specification, SRS is a specification within the context of an overall workflow solution that satisfies the business process requirements. The workflow itself is inseparable from the technology that is related to the workflow, technology is used here in its broadest sense. Consider the introduction of the “check” that can only be cashed by the person that the check is made out to. In our loan example, for an operation 100 years ago, such a concept (technology) would change the whole workflow solution. Now the workflow could be to have the client come to the office and receive the check then sign a receipt. The question may arise, what if the client wants cash? This is a mute point as the requirement or specification does not specify the use of a check but merely What is required. The use of the check does alter the workflow and is introduced by the workflow designers as a response to the newer technology providing a more cost effective solution to the overall requirement, i.e. that access to the money would be given to the customer on a specified date and time.
Now let’s consider software as the enabling technology.
The first issue with software as a technology (regarding specification) is that its function is flexible as opposed to simpler technologies such as a check or calculator. The problem this gives to the workflow designer is they need to understand the potential usage of any software component within various workflow possibilities in order to come up with the optimal workflow design that satisfies the business processing requirements. When this is achieved the Software Requirements Specification can be produced and handed over to the development team. Typically this situation leaves the workflow designers asking the software developers “What can you do for me?” while the software developers will be asking “What do you want?” In many ways it is this communication that leads to iterative, or prototyping development cycle’s that are favored in Agile and other (i.e. JAD, RAD) software development frameworks.
The second issue with software specification is that the required behavior of the software, in data processing systems, can be specified as a set of procedures or functions. When this is done the software specification begins to look like a software program. This causes confusion in that in blurs the What versus How boundaries of the specification. With the introduction of techniques such as class diagrams (in UML) for the software specification it is becoming possible to directly derive the executable code from a software specification model.
Regardless of the form of the SRS it is important to note (as in traditional engineering) that the Software Requirements Specification is targeted at a technical audience (software programmers) and represents a sub set of the overall business process requirements.
|
|
|
Conclusions
In conclusion we can say that the relevance and implementation of a specification, as distinct from requirements, is easier to understand and embrace in a traditional engineering environment where a tool or utility is to be a part of the overall solution. In commercial (data processing) software there are two main issues with the specification.
Firstly the workflow and the software solution are inseparable. Knowledge of the software capability (which is flexible) is required before the optimal workflow can be designed.
Secondly a software specification, that lays out what is functionally required, can be as detailed as the program code and it is difficult (and time consuming) to maintain the SRS and keep it in step with the software program. Sections of the SRS look redundant after the software is produced, in that the code repeats the functional specification. In traditional engineering this is not the case, the product or component specifications (for a customer requirement) are not documented in a form that relates to the production, i.e. the engineering specification consists mainly of measurable attributes that the product needs to satisfy or parts diagrams of what the product should look like.
|
|