How prototyping in real-time can elicit software requirements and boost creativity
Capture requirements faster and combat missed requirements with rapid iterative prototyping workshops
Eliciting software requirements is hard. Business analysts are faced with the challenge of understanding stakeholder demands, empathizing with users and communicating those requirements to software engineers. And those are just the foreseeable problem areas! Add changing market circumstances, pressure from the competition and stakeholders that don’t keep you in the loop, and eliciting effective requirements can start to look like mission impossible.
With these cumulative pressures, it’s not surprising that creativity is not a priority for business analysts when eliciting requirements. Most BAs might assume that capturing software requirements and managing them is enough already; creativity can take a hike.
But capturing requirements and creativity don’t have to be mutually exclusive. In fact, adding a little innovation to the the elicitation stage can in fact result in better software requirements and smoother software development life cycles.
That’s why the Justinmind team was excited when we found out about JAM sessions – a methodology thought up by software consultancy OneSpring a decade ago to elicit and visualize requirements by prototyping in real-time.
JAM sessions allow BAs and UXers to conduct requirements cycles up to twice as fast, and reduce requirements defects by at least 80%, claims Onespring. It’s an approach worth trying out if you’re looking for a different way to capture and visualize software requirements.
Let’s take a look at how JAM sessions can be implemented.
If you’re interested in requirements visualization then check out our FREE WEBINAR
Elicit software requirements with Justinmind Enterprise.
What are JAM sessions and how can they capture software requirements?
A JAM – Joint Application Modelling® – session “is a way to capture requirements in the raw”, according to OneSpring. It’s used by teams who:
- are spread out over several locations
- want to elicit, validate and visualize in real time
- want a faster way of getting to the heart of a product’s functionality.
JAM sessions don’t replace more traditional methods of requirements elicitation, but they can be a good supplement. In a typical session, attendees will build a quick prototype based on requirements elicited in session, visualize and refine that prototype, then validate and expand the proposed software.
How to organize a JAM session
A JAM session should take place over 2-3 days and involve groups of no larger than 10, to ensure full participation. If you need to include more stakeholders, hold more sessions. Attendees can range from stakeholders to potential users and product team members.
Apart from attendees, there should be 3 key figures taking part in the sessions:
- Facilitator, to lead elicitation activities
- Visualization Analyst, to capture and manage requirements
- Visualization Designer, to build those requirements into interactive prototypes
The whole point of a JAM session is that requirements are visualized from the word go. The Facilitator elicits big picture requirements and the Visualization Analyst uses a prototyping tool like Justinmind to rapidly design an interactive solution to requirements.
The application prototype can be immediately simulated on a screen projection on even on stakeholders’ mobile devices, so they can see their ideas in action. Then requirements are refined and the Visualization Designer iterates in real time. The Visualization Analyst keeps track of the requirements; in Justinmind’s Enterprise version you can link requirements to specific UI elements and version history the changes.
The benefits of requirements elicitation through JAM sessions
JAM sessions boost creative flow by breaking down barriers between various stakeholders and forcing them to move beyond their prejudices. There will also be a greater sense of shared purpose around the software, something that’s often lacking when requirements elicitation turns into a conflict between different players.
Allowing stakeholders to visualize requirements as soon as they think of them means there will be fewer missed requirements, and fewer late-stage changes. There’s more chance of reaching a consensus on how the software should function, and higher stakeholder engagement. The resulting interactive prototype with in-built requirements will be a lot easier to understand than paper requirements documentation. Plus session attendees participating remotely also get to see their suggestions iterated in real-time in the prototype.
How to prototype in real-time: Justinmind tips
Prototyping a software application in super-fast time can be a daunting prospect. Luckily Justinmind has some great time-saving tricks and features that will enable the Visualization Designer to keep up with fast-paced JAM sessions.
- Use Masters to apply global changes across as many screens as necessary
- Reuse content with Templates
- Create a custom library of branded assets and insert them into any interface with a quick drag and drop
- Use the 50+ keyboard shortcuts recognized by Justinmind
- Take advantage of ready-made UI assets for all devices
- Add Hotspots to create interactivity with one click
The Visualization Analyst can keep requirements organized even at high speed thanks to Justinmind’s integrations with Atlassian JIRA and Microsoft TFS: it’s easy to keep track of your requirements across different tools, and avoid rework by importing issues and tasks so you don’t have to create requirements from scratch repeatedly. Find out more speeding up your prototyping process with Justinmind.