Software requirements specification in the real world – The good, the bad & the ugly

By Tobias Andersen

??

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

• It includes a set of use cases that describe all the interactions the users will have with the software.

• In addition to use cases, the SRS also contains nonfunctional (or supplementary) requirements. Non-functional requirements are requirements which impose constraints on the design or implementation (such as performance engineering requirements, quality standards, or design constraints).

Definition according to wikipedia...

Why do we need a SRS...

Why?

At a glance...Where REQUIREMENTS can help

What often happens...Ba

d Re

quire

men

ts

Bad

Assi

gnm

ent

You cannot build what you do not understand

No amount of SPIN can replace a quality product

Starting off wrong, leads to a short lifeBa

d Re

quire

men

ts

Bad

Exec

ution

Bad

Valu

e

Bad

Long

evity

Bad Input leads to Bad outputBa

d Re

quire

men

ts

So what is a better way?

The SRS lifecycle

Its not a science

Can I do it?

The Good (Case 1)

• Project brief: Substitute X resource with Y resource on the clients corporate website. UX have created a ”resource map”, which is located on our internal project server.

• Projected duration: 1 business day.

• Estimated rate of success: >75%.

The Good (case 1) it was a piece of cake.

• Technical brief: Substitute X resource with Y resource on the clients corporate website at ftp://mysite.com.

See sitemap from UX @ \\{server}\{project} for further details on the resource-2-page mappings.

• Actual development time: 1½ business day.

• Actual rate of success: 100%.

The BAD (case 2)

• Project brief: Substitute X resource with the document we uploaded last month to our clients corporate website.

• Projected duration: ½ - 1 business day.

• Estimated rate of success: 75% <> 50%.

The Bad (case 2) we got lucky...

• Technical brief: Substitute X resource with its predecessor (unknown document, ask Claus he worked on it a month ago) on the clients corporate website at ftp://mysite.com.

See sitemap from UX @ \\{server}\{project} for further details on the resource-2-page mappings.

• Actual development time: ½ business day.

• Actual rate of success: 50%.

The UGLY (case 3) it’s not a science, it’s black magic

• Project brief: Hi Tobias. ”Your account manager asked me to forward you this email discussion that describes our change requests. If you have any questions feel free to contact me (p.s: I might be busy, but leave a message and I will get back to you ASAP.). Have a nice day! ”

• Projected duration: ? business day.

• Estimated rate of success: <25%.

The Ugly (case 3) not even the Beauty could love this Beast

• Technical brief: Read this email thread and do the needful!

• Actual development time: Just bill the client by the hour. Job nr. is 00911.

• Actual rate of success: 0%.

What have we learned

• A well-crafted SRS document mitigates risk.• SRS does not have to be 50 page documents.

It can be something as simple as a set of use cases defining the clients needs.

How to convert the Ugly into the Good

• When in doubt ask your client. If they don’t know, chances are you don’t need to know.

• Express your needs in a form that a 5 year old could understand!

Good Input enables Beautiful output