Defining a Software Product: Medical App

Defining a Software Product: Medical App

Today’s topic will focus on some of the introductory steps to define a software product by establishing the functional and non-functional requirements, elaborating user stories, a wireframe to show the UI of the website, and setting the competitive advantage. These points are the simplest of the whole process and provide a good starting point to validate an idea. For the purpose of this exercise the software will be a task management app for clinical settings called MedicaDM.

System Requirements

The requirements are the functions that the system should be able to perform to meet the various stakeholders needs and requisites. They consist of both functional requirements that describe what the software should be able to perform to meet the user’s needs and non-functional requirements that set the standards of how it operates, such as security and usability.

Functional Requirements

For this exercise the app will have the following functional requirements:

– User needs to provide credentials in order to view his user panel.

– User needs to provide credentials in order to view his user panel.

– User should be able to add tasks and assign them to themselves or other users.

– Admin user and users classified with supervisor access can delete or edit tasks assigned to him and others.

– Tasks should be able to be marked as done.

– There should be filters that allow the user to see completed tasks, those that are pending and their deadline, and those that are overdue.

Non-functional Requirements

Examples of non-functional requirements for MedicaDM:

– Auto-complete recommendations are enabled for text input fields.

– Redundancy in servers to ensure there is always working access and data.

– Response time should be no longer than two seconds.

– A 99 percent maintainability for 24 hours.

– Patient anonymity for data stored for analytics purposes.

– Cross-platform functionality in Android, Windows, and iOS (starting versions should be specified).

User Stories

User stories are one of the tools of agile development where in a concise manner the stakeholders state what feature they need. Because of their clear and brief nature, they can be understood quickly without highly-technical details and a need for further explanations from the user while developing. User stories can be written in a single sentence following the Connextra template:

As a <who, be it a persona or role> I want to <the desired goal/outcome> so that <the reason for that goal>

There are many variations of this template with some changing it to focus not on stating a goal but the benefit the user is looking for or including “when” and “where” in the template.

For this post I will be following the criteria by Jeff Nielsen shown here to define good user stories using the acronym S.I.T. As explained in his video user stories should be small, independent, and testable. In agile development user stories are set and completed for each iteration (development cycle that leads to a release, sprints in Scrum, you get the idea) so they should be small enough for developers to complete and test them for the following release. They should be independent of each other so that they can be completed in any order and without any dependency that may hinder development (not being able to work on one user story because another needs to be finished first). Finally, they need to be able to be tested. The other acronym used in agile development is INVEST, where in addition to the traits mentioned, user stories need to be negotiable with a space for discussion, they must deliver value, and the size of the user story must be able to be estimated.

With the acronym S.I.T. in mind and what we’ve discussed let’s look at five user stories appropriate for a project like MedicaDM:

– As a doctor I want to assign tasks to individuals to ensure the patient gets the right follow-up.

– As a nurse I want to be able to mark tasks as completed to ensure care coordination.

– As a resident I want to see the deadline for each pending round to be able to prioritize.

– As a doctor I want to see if there are any overdue tasks to make sure my team is providing a timely action.

– As a doctor I want to clearly see who is being assigned the task to avoid confusions.

Competitive Advantage – Efficient Iterations Based on User Interaction

Due to high competition, software products must find their competitive advantage, so it’s something someone in the team (ex. business development or marketing team) should be aware of. If the competitive advantage is communicated to the development team, the work they develop will be in support of this. Let’s say that for MedicaDM the way it pretends to be competitive is to be an app that focuses on simplicity and ease of use, given that the target market are users who can’t be troubled with a complex app due to time-constraints and urgencies. The competitive advantage would lie on low-cost iterative releases with only functions based on the latest users’ feedback. This increases efficiency since the team doesn’t lose time on complicated features that the user doesn’t yet require or use. Increasing efficiency with both time and resources would result of course in lower costs, which frees funds for marketing, securing more releases, research expenses (visiting the clients), infrastructure, technical resources, etc.

MedicaDM’s Wireframe

Now to land the idea a little bit better let’s look at a wireframe, a tool used for the design of UI’s to highlight how space would be allocated, functionalities, and any expected behavior or content. I used the tools provided by draw.io since it’s free and simple, but there are many tools out there depending on the complexity and features you require.

wireframe of a user panel

So what did we look at today?

– What functional and non-functional requirements are.

– What are user stories and what traits a good one should have.

– An example of a wireframe for UI purposes.

Miguel Morales

Leave a Reply

Your email address will not be published. Required fields are marked *