Requirements Gathering:
We had weekly meetings with our customer to accumulate all the requirements. We allocated half an hour per week for the discussion with the customer on Thursdays from 12.30 pm to 1 pm. We had even driven customer through all possible scenarios and garner all the best requirements for our activity tracker, inline with the customer’s needs and perspective. A couple of further add on features were suggested by our team to the customer citing proper examples elevating its significance and applications. All the requirements hence discussed over weekly meetings were finalized and we gathered a final broader list of requirements intended by the customer. During the process of gathering, requirements based on unrealistic expectation of the customer was taken into consideration and the customer was convinced accordingly. Customer categorized the desired requirements into Essential and Nice to Have features which really facilitated the consequent processes of Requirement Analysis and Specification which, in turn saved a lot of time.
Requirement Analysis:
All our team members played a vital role of Business analysts to figure out and analyze all the requirements to ensure customer satisfaction. Brain-storming among the team members was done as a part of internal team meetings to discuss and keenly observe the requirements. The functional (what the system does) and non-functional (how good and efficient) features were studied and the feasibility of the same were evaluated rigorously, by neglecting all the unrealistic expectation and providing the customer with feasible solutions. The feasibility of the requirements was tested collectively through careful observation and investigation of alike Applications available in the market. The sequence of all the tasks and requirements in the Application were prioritized based on customer needs to ensure proper plan and consistency throughout each phase of the Application. High level implementation of the application was prototyped and pictorially represented with all requirement aspects to categorize the requirements and to avoid conflict and ambiguity. The same pictorial representation of the app was shown and discussed with customer to clarify and validate all the requirements to avoid any chances of misconception and deviations from the customer’s requirements. Responding to change that is, Adaptability by altering certain requirements during the weekly customer meets was also done and a couple of wrong assumptions was also identified because of successive discussions with the customer. Proper interaction over tools and processes to be implemented. We conducted internal meetings to schedule the sub tasks in every phases.
Requirement Specifications to User Stories
All the requirements after customer discussions were set as goal definition. A strategy to implement the application throughout the desired time was formulated as a part of Requirement formulation. A pictorial representation of the overall app depicting the app features (adding category, super category), users (user view), views (category page, overview), design template, new ideas (graphs) was designed to get it validated during weekly customer meeting. This pictorial representation of the overall application was used to formulate and streamline the boarder requirements into more specific requirements. These specific requirements were further mapped to form user stories by splitting each requirement into its more specific subsets. These user stories along with proper understanding of product functionality, application and overview helped us in creating Use Case diagram and map each requirement to the desired ones.
User Stories
Sample Use Cases diagrams
Identifying Wrong Assumptions.
Certain requirements were misunderstood and interpreted in wrong way during the initial meeting time. The same was discussed and clarified with customer on later stages. One such assumption was the LOGIN feature. Our team had planned to implement the same as a mandatory feature, however it was suggested by the customer to make it an optional feature in the app since most users don’t prefer an application pin. Fortunately, we were able to make these changes in the requirement set.
Another Assumption was the parameters used for LOGIN. We assumed to use fields like username and password for logging in the Application. Through weekly meetings conducted with the customer, the customer desired to have a PIN of 4 digits rather than using username and password.