About us > Our work methodology > How we define requirements
How we define requirements
Requirements also define “what to do” in a project, although, with a deeper level of detail than what can be found in the Product Features of the Vision document.
There are several types of Requirements. We classify them as Functional and Non Functional (Usability, Reliability, Performance, Supportability, Implementation, Interface, Operations, Deployment and Legal).
Functional Requirements are among the most important because they define the core of the system, what the system must do, its features and capabilities. Functional Requirements are usually defined as User Stories or Use Cases.
We strongly think that requirements should be written by the customer with one or more members of the development team or, at least, participate actively in the requirements definition.
The best method to involve the client in the definition of the system requirements is by using User Stories because they are easier to conceive and because they are formulated in a more natural and spoken language.
User Stories
User Stories define a goal that a specific type of user has when using the system, in a natural language. Although it is not necessary to follow it, we use this format to describe the User Stories:
As a [type of user], I want/can/need/etc. [goal or need], so I can [reason].
An example of a User Story, for an e-learning web site could be:
As a Teacher, I want to create an online test, so I can measure the level of the students.
User Stories have a more important advantage. They are an easier method to have non technical involved people define requirements. For example, it is easier for a Product Owner to write a list of requirements in this format than in the format of a Use Case diagram or a list of Use Cases.
User Stories emphasize verbal communication, in comparison to written language. The use of the first person to describe the goal make them sound more natural and tend to avoid misunderstandings typical of a written document.
All the User Stories (or Use Cases or Features, depending on what we decide to use), along with any other requirement that is expressed in any different way are put together in the Product Backlog. This constitutes all what has to be done to complete the product.
We define the Product Backlog in a System Requirements Specifications (SRS) document and we manage it (time and resources) using a spreadsheet. The SRS document could contain additional information about each User Story. The Non-Functional requirements are also described in the SRS.
Acceptance Criteria
While the Product Backlog defines all what has to be done, sometimes it is risky to give the customer a fixed estimate or quote based only in simple User Stories or Features.
To solve this we sit together with the customer and go through each User Story and define what we call the Acceptance Criteria. This describes the high level features a User Story has to meet and the Tests it has to pass in order to be accepted as complete either by the development team or by the customer.
Examples of Acceptance Criteria for the above User Story could be:
As a Teacher, I want to create an online test, so I can measure the level of the students. Description
Acceptance Tests
|
