We’ve all heard that a “picture is worth a thousand words”. It’s absolutely true when it comes to building good software requirements. In the case of building a software application, even the most rudimentary prototypes elicit requirements that no one thinks of otherwise.
Within the business analysis community, the debate still reigns about whether how the application will look and how the screens will be laid out is technically part of requirements or design. This debate centers around the wrong question.
The right question is “When is the most effective time to introduce visual prototypes into your requirements process?”. My answer: As soon as it makes sense to do so.
Another good question to consider is “What requirements do a prototype or wireframe represent?” My answer: It depends. It depends on where you are at from a requirements process perspective (eliciting, validating, analyzing, or a bit of each), what types of requirements management practices you have in place, and what level of user interface expertise is available across members of the team.
I’ve worked on teams where the user interface wireframes or prototypes, coupled with some textual rules, formed the main body of functional requirements. I’ve also worked on teams where the prototypes were thrown away or merely used to capture representative screen shots. I’ve also partnered with a UI/UX Designer who creates the CSS/HTML for implementation alongside the functional requirements.
Regardless of where wireframes fit into the requirements package, they can be useful in all phases of the requirements process, from defining the scope to the implementation hand-off.
Using Prototypes During Initiation
During the initiation of a new project, some rudimentary mock-ups can help elicit new requirements and create alignment around project scope. These mock-ups might look nothing like the finished product, but showing one possible solution to a set of high-level business requirements can help get everyone is on the same page. It’s important to keep these wireframes very rudimentary, separating out look-and-feel to focus on the basic concepts to be introduced with the application.
Using Prototypes To Get to Detailed Requirements
As you start to dive deeper into the project requirements, wireframes become more tangible. I often create wireframes for an end-to-end work-flow, leaving gaps for areas that are open to trigger discussion points. It’s not uncommon for me to hold a walk-through and show off wireframes with bright red text and an arrow indicating “how should this work?” or “what should happen if the user clicks this button?” or “what if this rule is true?”. Walking through a new work-flow using visuals helps elicit hidden business rules, alternate paths and creates good discussions. Taking the wireframes through an end-to-end work-flow also helps drive some analysis. I often find gaps as I try to get from point A to point B to realize we have missed a field or an entire screen and overlooked an important requirement as well.
Using Prototypes to Validate Requirements
In the final stages, prototypes can also be used as a tool to vet the final rules. These rules are probably documented in a separate document, such as a UI specification, use case, or business rules spec. But rather than do a comprehensive document review, I sometimes talk through the rules in reference to the user interface. An example of this might be in an integrated environment when you are looking at a screen that is going to feed data to a native application. These rules will likely be documented in a spreadsheet of some kind with all the data mapping details, but instead of reviewing the spreadsheet I’ll bring up the UI screens and visually reference the mapping. So this field will go there…and then if the this field meets this condition, we’ll map it over there…etc, etc.
Interesting in seeing how prototypes can be part of your next project?
Learn to Create Useful Prototypes
Join us for Use Cases and Wireframes – a virtual, 4-week course. You’ll learn a time-tested approach for creating a use case and associated wireframes. With the professional credit option, you can earn 8 PDs/CDUs too.
Pingback: Tools for Prototyping – The Great Facilitator
When we are upgrading a system from A to system b. Because of end of life, the requirement gathering becomes a bit difficult. Can you suggest what questions we should list down to ask HR sme? Basically questions which comes to my mind is how policies will help the it admin later in entering the right data into the system.
Pingback: Using Wireframes or Prototypes to Elicit, Analyze, and Validate Software Requirements |
Pingback: A more thorough User eXperience steps breakdown « Code For Thought
This is a very good article. According to Laura, “wire-framing activities actually come before any sort of user interface specification “. So I am a bit confused regarding this statement. Becasue if the wire-frames are done before the specification/func specs, the what exactly the role of a BA? Because some times the person who does wire-frames will do all the research to what to display on a website. So the BA has to look at the wire-frame and just write a requirement. So how this would be a challenging/interesting job for a BA?
I guess I am looking at this as a technical UI specification but maybe it should be part of the requirement for the Users? In this case the numbers would confuse them?
So should I have 2 types of screen shots? One with the numbers and one with data?
Your right the data is not important to the stakeholders but more so to the implementation. So what I did was take the data sheet and added it as an Appendix A- Data Mapping. I left the numbers next to the labels on the screenshots but thinking maybe I should take them off. Not sure
Question when I am mapping labels should I have more than one label for the same thing? For example I have “Customer Name” on 5 forms in my spreadsheet should I repeat it or just refer to it one time?
Label 1 Customer Name
Label 8 Customer Name
Label 21 Customer Name
It depends. What question are you trying to answer by having the customer name listed multiple times? If you are answering a question that someone needs to review, approve, and implement and this is the best way to communicate the information, then I would say you are using the right approach. If not, consider revisions. It’s really hard to say out of context.
Well i did not get a feel of how they perfer to see it because i dont think they were there mentally in the process. They were just thinking about the form and i was thinking ahead about the form and the data.
Then it sounds like the feedback you are getting is that either the data is not important to your stakeholders or you as the BA need to educate them as to why it’s important and how they can provide you with appropriate feedback on your data requirements.
Oftentimes the best feedback we get is indirect.
Thanks laura, I did what u suggested. I took the screen shots then added textboxes with numbers in visit then pasted them into word with a coverage called web ui specification. Under each picture I placed a table with the label number,field name,datasource
We had a meeting and my boss was confused why I had the table. I explained it to him not sure what his take was on it or maybe I should have placed them in excel instead of under the photo. I was just trying to fit everything in one document.
From this meeting I will have to create 3 new forms for which there are no screenshots so I will attest to use visit until I can buy basliq.
thanks for ur help
You are welcome, Kai! There is rarely only one way to pull together a specification and feedback from others helps us revise our approach until we figure out what works best for us and those who consume our documents. Whenever we get feedback that something is confusing, it’s a great time to clarify expectations and ask questions about how the document will be used so we can suggest improvements to how we’ve organized things as well.
Can u elaborate on how I would have the wireframe and to convey the data that is to be mapped in the spreadsheet?
If the field names are the same, it should be easy (your spreadsheet just contains the same list of fields as displayed on your screen). Otherwise add a column to your spreadsheet to capture the alternative field name that’s used on the screen for clarity.
Currently have been asked to do a prototype/mockup to show the business what we will deliver however we don’t have any software? Its for an exisiting app we are adding functionality to so I don’t know how I can draw tabs text boxes on a screen shot?
Ideas please?
A low tech way is to create a screen shot, edit it in Paint, and make the adjustments in Word. It will be a pain in the neck, but it works. Or, perhaps, the old fashioned way of handwriting the changes and scanning them in as digital files to share?
Really, Balsamiq is so affordable (less than $100 the last time I checked), it might be worth paying for yourself rather than fighting without a tool.
Yes, Isabella, I agree that very few tools make the requirements concrete for sign-off like a visual. And supplementing the visual with user acceptance tests also seems like a very good approach to validating the requirements.
Sometimes BAs do need a thick skin to do the right thing and keep the project moving towards success, even when it might feel uncomfortable. Hate is a strong word, but I’ve definitely faced stakeholder frustration in a positive way. It’s important to also keep the stakeholder perspective in mind here and help them see how their input and further review will help the project be successful and serve their real goals in the end. You don’t want to become a barrier that they try to work around.
Hello Laura,
I highly agree with drawing the UI fairly early. It is an indispensible aid in eliciting requirements and increases the chances that they are complete, and lessens the chances of scope creep.
In my experience it is a toughie, but necessary to nail the stakeholder, client, down to describe how they want to determine if the requirement is fulfilled. Yes, plan the user acceptance test (UAT) right here. You’ll see your client winding, stammering, they want to escape the situation by “Not now, there isn’t any code yet”.
Dead wrong.
You need the information in order to write solid code. And it also leads you to undiscovered requirements, frequently collected under “non-functional requirements”. The functional requirements are that what the client wants and what the user will see, the non-functional requirements are the “plumbing”. What are they? Well, control tables or files, possibly some precautions for extensions without having to tear the house down later, in general, architectural decisions. Usually stakeholders have a bit of a problem with paying for what they don’t apparently see. Sell them the possible extensions, ease of maintenance. And get back to how they want to verify each requirement is complete. You do not need to get down to the nitty gritty details of test case development. Be precise with the words here. “We’re gonna find out later” is clearly not sufficient.
Example: Assume a requirement asks to pop a user form that is initialized with certain values depending on a selection made previously. The test criteria will be: Selection “something” in user control XXX on form ZZZ. Form AAA pops with the list box LLL filled. Source of the list box content is “whatever” in … Selection “something else” in user control XXX on form ZZZ. Form AAA pops with the list box LLL filled. Source of the list boy content is “whatever else” in … What will happen if the source for filling the list box is not available, for all the reasons you can think of? Describe the default setting. End of example.
Sounds exhausting? Yes it is. After you are through with it, give your client some time, say, a work week, to let it settle and sign it off. They’ll hate you, they want to get it off their desk. Your chance to get the developers to start working. Don’t worry about the hate. When the application is to their full satisfaction, hate will turn into respect.
@fkmolu no hard and fast answer, it depends on how the roles are defined. Here’s how I’ve filled a UI role as a BA http://bit.ly/RFax4