Software Requirements- part I

To develop and deliver a good software, understanding requirements is very important.
Here I will try to give a very brief idea on requirements.
So to start with :
What is a requirement?
In simple english , requirements are nothing but description or specification of a system.
A system can be anything , a 'table', a 'chair' or a 'software'.
If I am told to create a table , but I don't know where the table will be used , I might end up creating a very beautiful glass top , oval dinning table when the user wants a very simple , square shaped , firm , wooden study table.Similar is the case with software , I might end up developing a automated travel booking system when I was expected to create a complete software to help user book holiday packages.
So, it is very important to understand the business needs , the functional and the non-functional requirements of software you are going to create.
Here we have introduced three terms: Business needs, functional requirements; non- functional requirements. So what are these?
Business requirements: These generally define those characters that can enhance the business value of a product/software.
Functional requirements : These are the general functionality(behaviour) which the product/software being developed should possess.
Non-functional requirements :Non-functional requirements are characteristics that judge the behaviour(functional) requirements of the product/software.

Functional Requirements:
Functional requirements are general statements of services the system should provide.
A functional requirement is stated by a definite(or set of definite) input(s), a definite behaviour and an expected output.

Functional requirements define 'What' a system should do.

examples of functional requirements(for a banking software) :

1. Logging into a system

2. Transffering Money

3. Issueing e-checks

4. Viewing statements

5. Logging out of the system.

Non-functional requirements:

These are characteristics or behaviour of a system.

Non-functional requirements support the functional requirements.They define How a system should work.These are the behavioural attribute, quality attribute or constraints on a system.

examples of non-functional requirements:

1. Usability

2. Testability

3. Maintainability

4. Scalabilty

5. Performance

6. Security

7. Availability

8. Auditability

9. Licensing

10. Extensility

11.Portability

12. interoperability

13.Reliability

14. stability

15.Quality etc.

Business Requirements:Business requirements are too typical to a particular client.

These requirements generally run over business rules , metadata etc.

For example : Calculation of a interest over a particular loan may vary based different clients.

Business requirements at time also cover the ToM(Time to Market) and TCO (Total cost of ownership.)

Question:Can you tell if Installability ,Synchronization, help files are functional, non-functional or behavioural requirements?Justify your answer.

Installability :In my view installability is a non-functional requirement.

Reason : installability basically says on which platforms application can be installed.

Synchronization:I will classify synchronization as a functional requirement .

Help :Help again is a part of documentation and training , which comes as a non-functional requirement.

Characteristics of good requirement:

Following are characteristics of a good requirement, I call it 5C-OF-UMV.

1. Correct

2. Complete

3.Consistent

4.Cohesive - One requirement should only speak about itself.

5. Complete

6. Observable - Requirement is observable if no assumption with internal logic/architecture are stated.

7.Feasible

8.Unambigious

9.Mandatory : In absence of the requirement product/software is unacceptable unless stated otherwise.

10. Verfiable

Who should define requirements?

Ideally requirements should be defined by all stakeholders for a product including beneficiaries and customers.

Who should know the requirement?

Ideally whoever is directly or indirectly linked to a particular product/software being developed , ranging from Product Manager, Project Manager , to developers and testers everyone should have a clear picture of what is expected out of a product.

Does requirement change?

Generally high- level requirements do not change, they remain same from start of a product till the product is in market but at times the features for some of the requirements might change.

For example , if my requirement is a software which does arithmetic calculations for me is my requirement. My requirement may change from a basic calculator to a scientific calculator but my base statement of requirement of a calculator hardly changes.

In this article I tried to explain the very basic things about requirements , in next article we will see requirements in further details.