Our Trainer thoughts on Requirements

We interviewed Pentland Lead Requirements Engineering trainer on the subject. Here's what we learned from David Orme who has plenty to say on the subject:

What is a requirement?

 Here are the IEEE definitions of "requirement":

1. a condition or capability needed by a user to solve a problem or achieve an objective
2. a condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard,specification, or other formally imposed document
3. a documented representation of a condition or capability as in (1) or (2)

In laymen’s terms it translates as:

a singular documented need of what a particular product or service should be or perform.

·  Business requirements describe in business terms what must be delivered or accomplished to provide value.

·  Product requirements describe properties of a system or product (which could be one of several ways to accomplish a set of business requirements.)

What types of requirements are there?

Requirements can cover a wide range of needs. For example “we need this by July”; “we want to allow customers to place orders over the web”. As such requirements need to be split into their various types.

The Information systems examination board use the following types:

Functional: What the system should do (i.e. tasks/functions)

Non-functional: How the system should perform (i.e. response times, access restrictions)

 General: Constraints placed upon the project ( i.e. legal, time, cost etc)

 Technical: Hardware and software needs

What are the challenges we face in collecting requirements?

There are many problems associated with requirements engineering, including problems in defining the system scope, problems in fostering understanding among the different stakeholders affected by the development of a given system, and problems in dealing with the volatile nature of requirements. These problems may lead to poor requirements or the development of a system that is later judged unsatisfactory or unacceptable, has high maintenance costs, or undergoes frequent changes. By improving requirements elicitation, the requirements engineering process can be improved, resulting in enhanced system requirements and potentially a much better system.

How do I know when I have  good requirement?

That’s something that is completely open to interpretation. In my  opinion, a good requirement is one that is complete, clear and accurate. It communicates what it is supposed to, without leaving any gaps, and with no ambiguity.

What do we need to document for each requirement?

There are many templates that can be used to document each requirement in a catalogue. Each organisation needs to determine what their content should include to enable them to say what that requirement  does, and gives them something to compare against to confirm that it does what it should. It also gives the customer a way to check what the solution does when deciding how to use the software to meet a business need, and deciding whether the program needs additional functionality to meet a business need.

Can diagrams help?

Yes, it definitely can. Diagramming or modelling helps customers visualise better. It also helps to check for completeness of requirements at an early stage. The saying goes ‘a picture is worth a thousand words’ and when applied to the Requirements Engineering process it allows more to be shown in less space.

Is prioritisation important?

Very much so, prioritisation provides transparency to the business and allows them to make informed decisions when deciding on the scope of the project. In other words, they will understand where the money will be spent and that it is spent on the most critical requirements.

How do we make sure requirements don’t fall between the cracks?

Sometimes with the best will in the world requirements can get left behind in the stampede to complete the project. To stop this from occurring we need traceability. Traceability is one of the essential activities of good requirements engineering. It is used to ensure that the right products are being built at each phase of the software development life cycle, to trace the progress of that development and to reduce the effort required to determine the impacts of requested changes.

Traceability is used to track the relationship between each unique requirement and its
source. For example, a requirement might trace from a business need, a user request, a
business rule, an external interface specification, an industry standard or regulation, or to some other
source.