Developing an online shop is a multi-tiered process that needs to be planned in advance. Every customization should be properly prepared. The development process involves multiple stakeholders like entrepreneurs, customers, developers and other decision-makers having their own specific requirements.
This article discusses the issues of making a specification in projects where crafting systems or software requirements are involved. It is intended to be a guide to those who need to fit this process into their already busy schedule. We usually like to think that we know what we want to have as an outcome of the development process. However, it is generally wishful thinking.
Living in the eternal “firefighting” environment which is a typical entrepreneur’s workday, there is simply no time to recall all your planned features to be embedded into your product (shopping cart platform) functionality. Thus, it is good practice to be familiar with how a proper technical assignment is composed.
What is the ground to start with when writing a Specification?
The essential standards, methodologies, and bodies of knowledge that mention TA (Technical Assignment), SRS (Software) or SyRS (System Requirements Specification) are:
• IEEE STD 830-1998
• ISO / IEC / IEEE 29148-2011
• RUP
• SWEBOK, BABOK, etc.
Let us describe some of them.
IEEE STD 830-1998
Describes the content and quality characteristics of a correctly compiled software requirements specification (SRS) and provides several SRS templates. This recommended methodology aims to establish requirements for the software being developed, but can also be used to help in the selection of proprietary and commercial software products.
ISO / IEC / IEEE 29148-2011
Provides a unified interpretation of the processes and products used in developing requirements throughout the life cycle of systems and software. It replaces the IEEE 830-1998, IEEE 1233-1998, IEEE 1362-1998 standards.
This standard contains two requirements specification templates:
• System requirements specification (SyRS);
• Software requirements specification (SRS).
System Requirements Specification (SyRS) defines the technical requirements for the selected system and the ease of interaction of the proposed system and a person. It defines the high-level requirements for the system from the point of view of the subject area, as well as information about the general purpose of the system, its target environment and limitations, assumptions and nonfunctional requirements. It may include conceptual models designed to illustrate system content, use cases, core entities of the subject area, data, and workflows.
What’s the difference between SRS and SyRS?
A software requirements specification (SRS) involves the detailed descriptions of the developed software.
A system requirements specification (SyRS) provides information on the requirements that the developed system should meet.
Sometimes, the terms “Software” and “System” can mean the same. However, SRS normally provides a more granular view with more details about requirements than in SyRS.
RUP
Stands for the Rational Unified Process. RUP is a document that describes the artifacts obtained throughout the requirements specification process.
The SRS template in RUP is adapted from the IEEE STD 830 standard and contains two options:
• A traditional SRS template with structured functional requirements for System functions, as close as possible to the Standard 830.
• Simplified SRS template with the structured functional requirements such as use cases.
Why write a specification?
A software requirements specification is the ground on which the whole project stands. It outlines the basic principles that the development team will comply with, and not only. SRS is used as a reference guide to multiple teams — development, quality assurance, operations, and maintenance. That is how everyone involved in the project is kept on the same page.
SRS is like a test paper: it reveals what must be done. If something is not written in it, it is out of the scope of the final deliverables and is subject to another specification or one more revision.
Preparing an SRS can also reduce the time and cost of development. It contains the workshare. Thus, everybody understands what to do and what is the right stage for this.
*For the sake of this article, we will describe the SRS document as the basis for preparing a specification for developers.
How to prepare an SRS Document?
While the SRS document can save your time on development, you should write it properly to benefit from this. To do this, follow these simple rules of effective SRS writing.
1. Build an outline (at least, follow an SRS Template)
A good practice is to apply a template taken from a reliable source (IEEE is a good choice). But you are free to invent it by yourself.
2. Describe the purpose
Before stating the requirements for your project, you should define why the system is built: what problems it solves and what you expect from it after the product is developed.
3. Describe the product characteristics
Your product is your system or software as a whole or features you want to embed into your software/system. It can be the entire website or an extension to an existing piece of software – an add-on. No matter what it is, your product should be described: defined, equipped with a list of characteristics, expected behavior and so on.
4. Specify the requirements
Add more details to your specific requirements for building your product. This will guide the developers.
Closing
Clear requirements help development teams create the right product. And a correctly composed specification helps you lay the groundwork for product development.
A specification can be implemented in a form of standalone documents to describe the requirements for a system and software like SRS and SyRs, or more specifically, – FRD (Functional Requirements Document), RD (Requirements Document), TA (Task Assignment), etc. But these are all derived documents from the standards mentioned at the beginning of the article. With proper use of any of the above standards, you can take our recommendations for writing a technical specification adapting it for your online shop or marketplace needs.