How to compile software requirement specifications (4)

Address: http://www.microtoolsinc.com/Howsrs.php

How to Write a software requirements specification

How to compile software requirement specifications

By Robert japenga

__________________________________________________________________________________________

What are the characteristics of a great SRS?

What are the characteristics of excellent SRS?

Again from the IEEE Standard:

An SRS shocould be

A) Correct

B) unambiguous

C) Complete

D) Consistent

E) ranked for importance and/or stability

F) Verifiable

G) modifiable

H) traceable

Again from the IEEE Standard:

SRs should have the following features:

A) Correct

B) unambiguous

C) Complete

D) Consistent

E) sort by importance and/or stability

F) Verifiable

G) changeable

H) trackable

Correct-This is like motherhood and apple pie. of course you want the specification to be correct. no one writes a specification that they know is incorrect. we like to say-"correct and ever correcting. "The discipline is keeping
Specification up to date when you find things that are not correct.

Correct-- This is like perfect. Make sure that the expected specifications are correct. No one knows the error, but writes the error to the specification. We prefer to say "correction and continuous correction ". This rule means that once you find that the spec sheet exists, correct it in time.

Unambiguous-An SRS is unambiguous if, and only if, every requirement stated therein has only one interpretation. again, easier said than done. spending time on this area prior to releasing the SRS can be a waste of time. but as you find
Ambiguities-fix them.

Unambiguous-- If there is only one explanation for each requirement, SRS is unambiguous. Furthermore, it is easy to say. It took a lot of time before SRS was released. But once you find the ambiguity, you can fix it.

Complete-A simple judge of this is that is shoshould be all that is needed by the software designers to create the software.

Complete-- It should be noted that software designers must design the content when designing the software.

Consistent-The SRS shoshould be consistent within itself and consistent to its reference documents. if you call an input "Start and Stop" in one place, don't call it "start/stop" in another.

Consistent-- The SRS document should be consistent with other references. If you call an input "Start and Stop" in one place, do not call "start/stop" in another place"

Ranked for importance-Very often a new system has requirements that are really marketing wish lists. Some may not be achievable. It is useful provide this information in the SRS.

Sort by importance and/or stability-- Generally, the demand in the new system is the true market wish list, and some may not be realized. Therefore, such information must be provided in SRS.

Verifiable-Don't put in requirements like-"It shoshould provide the user a fast response. "Another of my favorites is-" The system shoshould never crash. "Instead, provide a quantitative requirement like:" Every key stroke shold provide
A user response within 100 milliseconds ."

Verifiable-- Do not include requirements such as "quick response should be provided to users", or "the system will never crash ". In fact, quantifiable indicators need to be provided, for example, "the response time of each press Key is within Ms ".

Modifiable-Having the same requirement in more than one place may not be wrong-but tends to make the document not maintainable.

Changeable-- It is not an error to have the same requirements in multiple places, but the document maintenance workload will increase.

Traceable-Often, this is not important in a non-politicized environment. however, in most organizations, it is sometimes useful to connect the requirements in the SRS to a higher level document. why do we need this requirement?

Trackable-- Traceability is generally not required in a non-political environment. However, in most companies, it is very useful to associate the requirements in SRS with the content in the superior document, so that you can see why these requirements exist. [Translator's note: The requirement tracing tool can use a tracking matrix in Excel format, as well as a commercial reqtify tool]

 

How to compile software requirement specifications (1)

How to compile software requirement specifications (2)

How to compile software requirement specifications (3)

How to compile software requirement specifications (4)

How to compile software requirement specifications (5)

How to compile software requirement specifications (6)

How to compile software requirement specifications (7)