Difference between revisions of "Guidelines on writing Software specification"

From X-Cart 4 Classic
Jump to: navigation, search
Line 3: Line 3:
 
A Software Requirements Specification (SRS) is a complete description of the behavior of the system to be developed.  
 
A Software Requirements Specification (SRS) is a complete description of the behavior of the system to be developed.  
  
 +
In our [http://www.qtmsoft.com/custom_development_agreement.html Customization Agreement] it is mentioned as "Specification for Software Modifications" (or just Specifications). It's the only place describing changes to be made within a custom task. If something is not well-noted there, it's not taken into consideration while evaluating a project cost and therefore won't be implemented.
 +
 +
This article explains how to write a task specification thus save your and our time.
 
==How to write good requirements for software product==
 
==How to write good requirements for software product==
  
Line 103: Line 106:
 
==See also==
 
==See also==
  
[[http://en.wikipedia.org/wiki/Software_Requirements_Specification][SRS on Wikipedia]]
+
* [http://en.wikipedia.org/wiki/Software_Requirements_Specification SRS on Wikipedia]

Revision as of 17:57, 25 March 2010

Introduction

A Software Requirements Specification (SRS) is a complete description of the behavior of the system to be developed.

In our Customization Agreement it is mentioned as "Specification for Software Modifications" (or just Specifications). It's the only place describing changes to be made within a custom task. If something is not well-noted there, it's not taken into consideration while evaluating a project cost and therefore won't be implemented.

This article explains how to write a task specification thus save your and our time.

How to write good requirements for software product

See #Template for SRS.

Requirements analysis checklist

The requirements checklist contains a list of questions to ask yourself about your project's requirements. Not all of the checklist questions will apply to your project. If you're working on an informal project, you'll find some that you don't even need to think about. You'll find others that you need to think about but don't need to answer for-mally. If you're working on a large, formal project, however, you may need to consider every one.

Specific Functional Requirements

  • Are all the inputs to the system specified, including their source, accuracy, range of values, and frequency?
  • Are all the outputs from the system specified, including their destination, accuracy, range of values, frequency, and format?
  • Are all output formats specified for web pages, reports, and so on?
  • Are all the external hardware and software interfaces specified?
  • Are all the external communication interfaces specified, including handshak-ing, error-checking, and communication protocols?
  • Are all the tasks the user wants to perform specified?
  • Is the data used in each task and the data resulting from each task specified?

Specific Non-Functional (Quality) Requirements

  • Is the expected response time, from the user's point of view, specified for all necessary operations?
  • Is the level of security specified?
  • Is maximum memory specified?
  • Is the maximum storage specified?
  • Is the definition of success included? Of failure?

Requirements Quality

  • Are the requirements clear enough?
  • Does each requirement avoid conflicts with other requirements?
  • Are the requirements at a fairly consistent level of detail? Should any requirement be specified in more detail?
  • Should any requirement be specified in less detail?
  • Is each item relevant to the problem and its solution? Can each item be traced to its origin in the problem environment?
  • Is each requirement testable? Will it be possible for independent testing to determine whether each requirement has been satisfied?

Requirements Completeness

  • Where information isn't available before development begins, are the areas of incompleteness specified?
  • Are the requirements complete in the sense that if the product satisfies every requirement, it will be acceptable?
  • Are you comfortable with all the requirements? Have you eliminated requirements that are impossible to implement and included just to appease your customer or your boss?

Template for SRS

1. Project summary

Опционально.
Краткий перечень модификаций, при этом допускается указание цены за каждую модификацию.
Описание процесса протекания и результатов продаваемого сервиса.

2. Terms and Definitions

Опционально.
Определение некоторых нестандартных терминов или переопределение привычных терминов.
Ссылки на связанные модификации для пояснения текущей функциональности и терминов.

3. Environment

Обязательный пункт. Название продукта, версия, прямой линк на софт, на котором должна быть проведена модификация.

4. Functional requirements

Roles:

- Store owner
- Registered User
- Visitor

USE CASE "Название use case 1"

USE CASE "Название use case 2"

USE CASE "Название use case 3"

...

USE CASE "Название use case N"


5. Other requirements (non-functional and system)


6. Exclusions

[features that are not supposed to be implemented]

Опционально.
Изменения, упомянутые клиентом, но не получившие развития при обсуждении или намеренно не включенные в спецификацию.

Appendixes

[graphics and other materials]

Example of SRS

See also