Shared requirement is an important thing when trying to have quality software. Software requirements simply record four main things: the user and his purpose, the data stored, the rules and also the limits, to the gap between impractical conditions to something more practical. Many approaches to innovating in a software requirement such as design thinking approach, user centered analysis & design, object-oriented analysis & design, and of course the requirements engineering approach. But whatever the approach, the same thing is all the needs and problems come from the user. On this occasion we will use a design thinking approach. Design thinking simply addresses the three statuses in developing requirements namely problem (pain), needs, and proposed solutions. The culmination point in a software development is the existence of innovation that acts as a value proposition or unique solution advantage compared to before.
medianet_width = "600";
medianet_height = "250";
medianet_crid = "858385152";
medianet_versionId = "3111299";
Three principles design thinking in software development
Starting with the user research. User should be researched for their problems through several options of elicitation. We can do observation, interview, and questionnaire to understand the users pain point.
Doing creativity. Creativity about how to turn something impractical into practical. With of course considering various existing limitations.
Making through learning. Understand that software development is an ongoing process. so realize that the process of software development is not a one-time but rather incremental and iterative
Four steps to do design thinking in software development
Step 1. Understanding the user.
Who are the users?
What their pain points?
Ask them about how the problem 'might be' solved
Ask them about the constraints they have?
Step 2. Explore and Sketch
Focus what is the most important. Rank their pain points & needs.
Do brainstorming with the users
Think analogy by looking similar solution for similar problem
Step 3. Converging the solution
Converting users into specific users (persona)
Building the prototype for the persona.
Doing user acceptance test to validate your prototype.
Changes idealism into realistic prototype
Step 4. Testing and Learning
Evolutionary based on feedback
Stay open with changes
Have a good reason to changes otherwise stay on track
If you want to learn more, I will create a real example, just post in the comment
medianet_width = "600";
medianet_height = "250";
medianet_crid = "858385152";
medianet_versionId = "3111299";
Kano Model This article will cover you the basic uderstanding about the Kano Model. Kano from the name of Dr. Kano, is a quality mode or estimation model based on the user requirements. Model Kano works suitable with CTQ (Critical to Quality) characteristics. CTQ will remember you what the Agile principles said “YAGNI” – You aren’t gonna need it. YAGNIS is a principle when we want to develop a software feature for the tomorrow requirement without the need from the user. CTQ has three categories Must be / Essentialy Needed / Basic Deliver Performances / Business Value / Performance Delighter / Nice to Have / Excitement Please beware that the priority is different than story points on a user story. it justifies a feature based on priority. Some peoples also use M-L-E-I-R-Q model (please the reference for more information about this). it gives you a wide selection of priority and it will be great if you use questioner for this approach, whereas the three categories above is great when it is implemented for observation or interview. Quick Steps on Agile Estimation Choosing the right model of requirements approaches (interview, observation, or questioner). Choosing the right model for priority model (Kano, MOSCOW, simple numeric, etc) Sort out the story based on its priority Give the story its story points. Measuring the release length and iteration length. Filling the user story into the iteration release. you can put the story based on several technique such as normalism techniques (gaussian), important thing first, or equality technique Example For example, I have questionere the potential users. and use KANO model with M-L-E-I-R-Q. I got 3 story M, L, E 7 story I 3 story R, and Q Let’s make it simple, if M, L, and E category has 20 story points so that I have 60 points (3 x 20), if I story has 10 points therefore I will have 70 points (7 x 10), and if R & Q has 5 points, I will have 15 points (5 x 3). It has 95 points. If my team has velocity of 30 story points, and the contract is based on cost scope on two months. Therefore it will have only 60 story points / realease. It shows that the project doesn’t cover the 35 points (95 – 60 points). It means you should select only 40 points from the I classification feature. In order to select the I features, you should re-priotize or do others requirements process to sort the I features based on the user need. You should remove 30 points and pick only 40 points from release plan References