The Bananaquits
The process to gather the software requirements from client, analyze and document them is generally known as requirement engineering.
Poor requirement quality is currently the number one problem in requirement engineering and solving it will go a long way towards improving software and system development.
Effective requirements engineering lies at the heart of a developer’s ability to guide the ship ad to keep pace with a rising hide of complexity.The process in requirements engineering are interleaved, and it’s done iteratively.
1: Interviews
The most common technique for gathering requirements is to sit down with the customers and ask them what they need.
There are many good ways to plan the interview, but we wanted to ask open-ended questions to get the interviewer to start talking and then ask probing questions to uncover requirements.
Gathering and understanding the requirements is a difficult process. That’s because customers may not know what exactly they want the application to do, or they may give un-realistic requirements.
2: Mind Map
We used the brainstorming method “Mind Map” to facilitate the Beginning of the interview.
Mind mapping is simply a diagram used to visually represent information. It is a powerful graphic technique used to translate what’s in the customers mind into a visual picture. Mind mapping increases the creativity and productivity because it’s an excellent tool to generate more ideas, identify relationships among the different data and information.
(filler Text Picture Viviane)
After the discussion with customer we formulated the requirements and analyzed them. According to IEE Std. 830 -1998 good requirements need to be:
• Unambiguous
• Changeable
• Complete
• Correct
• Reproducible
• Consistent
In addition to that the requirement were divided into functional and non-functional ones. A functional requirement describes what a software system should do, while non-functional requirements place constraints on how the system will do so.
The analysis of the requirements is really important because the customer may give different requirements, which will result in conflict between the requirements, so these conflicts have to be discovered.
After this we went back to the customer and talked about the details of each requirement.
Below you can see our first resulst of the Requirement Analysis:
In the next meetings with the customer we were able to close the gap in our understanding of what our application is supposed to do.
We specified the Requirements and use prioritization to structure and evaluate them.
Prioritizing our requirements will help us later to focus on the essentials and core features of the system, so we can meet the user expectations. During the requirements validation process, different types of checks should be carried out on the requirements. During the requirements validation process, different types of checks should be carried out on the requirements.
We did the Validation by requirement reviews with the customer (Investigation in great detail to check for erros, inconsitency and ambiguity) and in fact it’s an iterative process we are going to do it by prototyping.
• Completeness
• Comprehensibility
• Consistency
• Changeable
• Verifiability
Now we were able to create the Use Case Diagram and the User stories:
Here you can see our first Use Case Diagram and the second one, after further discussion with the customer:
The Use case Diagram is an effective technique for eliciting the requirements. But, because they focus on the interactions with the system, they aren’t effective for eliciting non-functional requirements.
Use Case Diagram 2:
The regular meetings with the customer and the specification of the requirements has led to the discovery of ambiguities. At the beginning of the project we thought that the creation of a database is an important part of the task. After the interviews and a detailed analysis of the task it became clear that this is not the case. The most important thing to avoid wrong assumptions are many meetings and discussions with the client.The more precise description, for example in the form of “User Stories” then show the last false assumptions.By building the Use Cases and the User Stories from the user’s perspective, we can identifie how the user interact with the product and what requirements need to be met to facilitate those interactions.
Now you can see the result of the requirements engineering process :
## User Stories
In the User stories we highlighted the essential Requirements in red, the necessary ones in orange and the desirable ones in blue.
But what is a User Story ?
A user story is a short simple description of a product feature from the prespectice of the customer who wants to use the feature.
Visualizing User stories and showing how they can bee accomplished within a sprint, works like a compass to keep all team members on the right track through development.
In the next few days and weeks we have to split the user stories in specific functions, Activities and tasks.
Thanks to our analysis we can easily determine essential task and organize work into sprints and build a User Story Map.
Estimate
Current State
.png "Pooja(estimates)")
Anna,Avanthi,Pooja,Viviane
Text & Design by Anna