Ten Checklist that you should have before developing a software

To build an information system, a comprehensive requirements document is essential. This document, often referred to as a System Requirements Specification (SRS), serves as a blueprint for the project. It details what the system is supposed to do and how it should perform, providing a clear understanding of the project's goals and objectives to all stakeholders involved. On this article, we discuss how to build Lean SRS, SRS that looks simply but answer almost any questions in building software. We discuss as ten checklist that you should have before developing a software Organization business process. This business process is a foundation for developing software. it discusses the business rules, vision, regulation, compliance, and holistic process of the software.  Application / IS business process. This business process captures the actor, the user requirements, and the process of the application that aligned with the organization business process.  Mockup of the application. This mockup describes the user interface of the application  Platform technology. This platform technology is approved technology that can be used to develop the information system Data architecture. This architecture discusses how data is stored, managed, and exported Software architecture. This architecture discusses how software component is composed into software solution  Infrastructure architecture. This architecture discusses how infrastructure is constructed to host the solution.  meeting schedule. This activity discusses how the schedule is created and managed so team and  change management procedure. This procedure discusses how the software will be managed for future changes release plan and project deliverable. The release plan and deadline of working feature.       that's it 10 things that you need to have before developing software

Design Thinking in Software Developments

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";

Agile Estimation? The Story of Kano Model

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

Topics Highlights

About @ridife

This blog will be dedicated to integrate a knowledge between academic and industry need in the Software Engineering, DevOps, Cloud Computing and Microsoft 365 platform. Enjoy this blog and let's get in touch in any social media.


Month List