Software Requirement Specification

-

Software Requirement Specification

What is SRS and its usages?

SRS (Software Requirements Specification) is used to describe the behavior of a system. SRS should include functional requirements and non-functional requirements. Funcational requirements tell you about what the software is used for and how it interact with users. Non-functional requirements tells how good the software should perform. Basically, it is some constrains imposed on the design and implementation (Remember every system has constraints, otherwise you will be able to do anything you want, that is unreasonable. So when you try to do something in life, find the constraints. This is not just about software development, it is pratical for everything). Take game development as an example. Functional requirement should think about what kind game it is, how to play it, how the players operate the console, etc. And non-functional requirements should consider how much footprint will be used, how the performance, the reliability (it should not go to crash frequently during playing), etc.
So SRS can be used as the guidance during the whole development period. It can be used as the basis of testing.

How to form a good requirements statement?

A good requirement should contain: Capabilities, Conditions, Constraints. 
However in the beginning, maybe you did not have an overall understanding of the system, so you can just state some capabilities, but as the progress carries on, you must complete the statements with conditions and constraints, otherwise the program cannot proceed.
  • Here ca pabilities are used to describe what the embedded system shall or must do.
  • Conditions are measurable qualitative or quantitative attributes and characteristics associated with the capability.One thing you need to know is when you implement one function. It must be associated with numbers or options. For example, when you design a blockbreaker game, you cannot just say I need to design blocks, panel and ball. You should say how many and how big blocks are, and the size of panel and ball, etc. Otherwise it is unrealizable.
  • Constraints is some limitations imposed on the requirements by circumstances, force or compulsion. It is something makes you design software in a limited environment, where you cannot do whatever you want. You should always be aware of these constraints when you design. For example, when you design a blockbreaker game, you should say these blocks should exist in a limited size of screen.
How to obtain requirements?

1, Getting Inputs
Get inputs from customers, environment and technical community.
Cusomers can provide:

  • Concept of operations/system concepts. Here we can know how the user operate the machine.
  • Marketing specifications
  • Request for proposals
  • External interfaces
    • Computer to computer
    • User to computer
    • Computer to sensors and actuators
    • Computer to data links
  • Feedback
Enviroment camn provide:
  • Political influence. For example, some countries may not allow some services, or they may require that the language on device have to be their local language.
  • Market influence
    • Market needs
    • Distribution and accessibility
    • Competition
  • Standards and Technical policies influence
  • Cultural influence. For example, you design a game in Iran, when players win, you put a THUMB UP picture in the end, they will kick your ass.
  • Organizational influence
Technical community can provide technical feedback from various perspectives:
  • Desgin
  • Implementation
  • Integration
  • Test
  • Manufacturing
  • Deployment
  • Operations
  • Maintenance
2, Identify and Analyze Requirements
Then we need to identify and analyze the requirements from inputs. Here you can discuss with customers, do surveys, observations, reverse engineering, simulations or prototyping, etc to identify and analyze the requirements. The goal of requirements analysis is:
  • Identify implicit requirements from the inputs and derive further requirements.
  • Identify mis-match or inconsistencies between requirements.
  • Identify missing requirements for further discussions with customers.
  • Identify missing requirements for further discussions with customers.
  • Identify workflow, patterns of behavior, attributes, system modes, data flow or capacity.
Techniques to analyze requirements:
- Scenario Analysis (Try to imagine scenario how users will use the system, and how the system response to users):
  • Very effective in systems involving some form of external stimuli (system interacting with some users)
  • Can be expressed in terms of use cases, sequence diagrams, flow charts, activity diagram, statecharts.
  • Starts with customers describing typical use scenarios.
  • Proceeds to consider different users or actors involved in the use of the system.
  • Exception scenarios are conceptualized, using various entry points in the typical use scenarios and asking "What if".
- Functional Analysis (analyze the functions the system contains, and try to analyze each function):
  • Very effective in analyzeing the inernals of the system
  • Very useful for autonomous and embedded control systems analysis
  • Often represented using function diagrams, data flow diagrams, control flow diagrams and even entity relationship diagrams
  • Starts with the interfaces and identify functions
  • Trace the data flows and event flows, to understand how data and event flows are handled
In most cases, scenario analysis and functional analysis are combined together to do requirements analysis. Scenario analysis is used when we design interfaces which need to interact with users, because here designers and customers can imagine how the user will operate it. And functional analysis is good for analyzing the internal functions of system: how many modules the system is composed of, how the data flow is passed. Functional analysis is for designers' perspectives. There are functional analysis examples from answering machine:

   
Function diagram
Data flow diagram
Event flow diagram
3, Organize and Review Requirements
When you finish all the requirement analysis, then organize well the requirements and make sure the requirements are:
  • Requirements are well-organized
  • Well formed. Follow the rules of capability, condition and constraints.
  • Readable.
    • Use a data dictionary to explain unique terminologies
    • Write with the customers or reviewers in mind
  • Testable. Keep testing of the software in mind, to make sure the test team can understand the testing tasks clearly, which can help the test team to test the system. Don't put them in a terrible situation where they think what the hell should I do holding the requirement specification document.


References: 
[1] List of system quality attributes, http://en.wikipedia.org/wiki/List_of_system_quality_attributes
[2] IEEE Recommended Practice for Software Requirements Specifications

Comments

Post a Comment

Popular posts from this blog

Basic understanding of TLS-PSK protocol

-
Image
This post will talk about the basic understanding of TLS-PSK protocol. It will not cover TLS's history and how its mathematical algorithms work. Instead, what is TLS-PSK protocol and how it works will be discussed here. I prefer using diagrams to help explain things. Hopefully, it can give readers a very basic insights of TLS-PSK. What is TLS-PSK Before talking about what is TLS-PSK, I would like to introduce what is TLS first. TLS, Transport Layer Security, is a cryptographic protocol, aims to provide protection to end-to-end communication over the internet. It helps to protect network users from eavesdropping, tempering and so on. Clear data transmission is dangerous, given that technical hacker can listen to the communication between two computers and steal sensitive data like user name, password and so on. This is situation where TLS can step in and protect you. TLS has two steps: TLS handshake and data transmission. During TLS handshake, the communicating parties mus...
Read more

Differences between ASIC, ASSP and ASIP

-
ASIC (Application Specified Integrated Circuit) is a customized integrated circuit. It is usually used by a person or company for a very limited usage. So when it is developed, only the person or company who orders it can use it. It is not useful for other usages, for example, an IC designed for a specific line of cellular phones of a company, whereby no other products can use it except the cell phones belonging to that product line. - ASIC is just built for one and only one customer. - ASIC is used only in one product line - Only volume production of ASICs for one product can make sense which means low unit cost for high volume products, otherwise the cost is not efficient. - Can exploit parallelism to achieve high performance - Low power consumption ASSP (Application Specified Standard Processor) is an integrated circuit that implements a specific function that appeals to a wide market, which means its function is specified for example a motor drive chip. But it is used widel...
Read more

Orthogonal instruction set

-
Definition: "In computer engineering, an orthogonal instruction set is an instruction set architecture where  all instruction types  can use  all addressing modes . It is 'orthogonal' in the sense that the instruction type and the addressing mode vary independently." The story of orthogonal instruction set: In the past, because the  memory is very precious , so the processor designer tends to  make instructions as powerful as possible . So they hope one instruction can perform  full function  like get data from memory and then perform the calculation. They make  all instructions can have all the addressing modes . By this way,  one instruction can fetch data and do the calculation at the same time .  But this will  inscrease the complexity  of the processor design. Also, accessing memory directly is very time-consuming, so some companies choose to use RISC processor (like ARM) which has a  LOAD-STORE a...
Read more