Scope:
To gather information in the form of user stories, business requirements and specific business needs. We were required to gather requirements from key stakeholders. For my team’s case, we were gathering requirements to provide a software solution to make our client’s fitness apparel store available online. Our client’s goal was to extend her customer base, and to make the user experience as pleasant as possible.
My role and solution:
In the group project, I was the appointed group leader after discussion with my groupmates. With this additional title, I made sure that the workload was delegated proportionally and ensured that everyone’s skill sets were fully utilised. For example, some of my group mates had a more analytical mind, so they were in charge of ordering and classifying the user stories. Others, such as me, were stronger in our languages and therefore were put in charge of phrasing and fine tuning the user stories and business needs before submission so that it made grammatical sense and was concise and comprehensive.
I also was in charge (opening/closing)of vetting the questions before we conducted the interview, and evenly split the questions/follow-ups between my groupmates.
​
My solution was to document sound business needs and user requirements which could enable the group to produce more effective and required system functionalities to make users have a better experience using the software solution derived, which would in the long run promote business and user traffic.
Work process:
There were several deliverables required for this particular project. This project was split into 2 portions.
PART 1
Group Interview
The first part was a group interview with the stakeholder who had engaged our services. As a group, we had to come up with good quality interview questions which returned concise information which could give us deliverables, needs and ideas to work with. It was a struggle to form questions that were not leading, as we wanted to ensure that we did not affect the stakeholder’s answers in any way whatsoever. We had 15 open-ended questions to facilitate the best and smoothest information elicitation process.
​
Product Backlog
After the group interview, we managed to gather sufficient information to direct us in the next step. We proceeded to create a product backlog that encompassed the use cases gathered from the stakeholders, which had a total of 23 use cases that were derived from the interview. These use cases are representations of what the various stakeholders (like visitors, system administrators etc) require and desire in the new software implementation.
​
​
Images of Interview Questions and Use Cases
(click for better readability)
PART 2
Next up is the individual portion of this project. I was tasked to create a use case diagram which showcased the design of the system from the end-user’s perspective. By describing all externally observable system behavior, it is a useful strategy for explaining system behavior in the user's words.
Use Case Description
I also made a Use Case Description table, which consisted of description, the primary and secondary actors, the use cases included and extended from it, the pre and post conditions for the use case described to happen. And most importantly, it illustrates the main flow of events, and even the alternate flows. The whole purpose of this table is to give a particular use case an in-depth explanation and it allows the use case to be put into the perspective of the larger use case diagram. And most importantly, it shows how it is interconnected with other use cases, more than just via lines in the diagram, but in actual form and stated flow of events.
​
Grouping and Ranking of Use Cases
Next up, I had to group and rank the use cases from the product backlog. I grouped the use cases by themes such as “Main product page” “Financial Aid” and “Product Management” . The ranking was on a scale of 4-1, 4 being absolute must-haves and 1 being features that do not necessarily need to be implemented immediately.
​
Non-functional Requirements
And finally, Non-functional requirements. These are requirements that do not necessarily affect the system’s ability to work, but will affect the user’s experience and this new system may not meet the user’s needs if it does not fulfil these NFR’s. It focuses on aspects such as security, availability, scalability etc.
Images for Part 2 (Individual portion)
(Click for better readability)
Conclusion
​
To conclude, this project has enabled me to learn how to manage a group of people, by utilizing their strengths to everyone’s advantage, throughout the duration of the project. I also learnt how to properly elicit information from stakeholders in an ethical and non-leading way. I was given the opportunity to really learn how to ask quality questions which promoted deep sharing and insightful knowledge. It was a fantastic learning experience, and I enjoyed doing this project a ton, especially the mock interview portion with our teachers.