17

Say you are given a mock-up of 25 screens of the visual states of your application. The expectation is that this is enough for us to be confident we can develop and hand it to the original stakeholder or customer as a finished application, and they will be satisfied. Naturally, you're going to end up asking the stakeholders many questions over again that were used to come up with the UI, which is wasteful.

However, I have many many times found that this is very much not enough, in the course of developing the application the requirements become blurred by the fact that we are replicating an interface and in the end the customer is not as happy as they first seemed when we asked them for all the info to create the UI.

I am just not sure what else to ask for, I have tried to be specific and ask for requirements and an understanding of the overall goal, but I don't know what I should ask for. If I just start now, lots of time is going to be wasted re-hashing all the info that lead up to the UI and during this phase many important reasons the customer originally had will be lost.

How can I get people to understand that we cannot lock down requirements based on UI mock-ups by asking for something actionable they can create for me?

What would you ideally start with in order to properly execute the task of developing an application for end users?

Bill the Lizard
  • 8,408
  • 9
  • 41
  • 92
MetaGuru
  • 2,663
  • 3
  • 22
  • 31
  • How are you asking for requirements? Are you simply going to the customer/user and saying "can I have requirements?" or are you using any of the various techniques to elicit, capture, and verify and validate requirements? – Thomas Owens Sep 21 '11 at 17:45
  • 2
    It's not easy dealing with non developers for this. Screens simply don't describe an application. My current employer does not understand this. My efforts tend to be geared on going through each screen and asking a lot of questions about behaviors of each item and "what ifs". That way you have a hope of isolating features and being able to design what goes under the gloss. – Rig Sep 21 '11 at 17:51
  • @ThomasOwens this is exactly what this question hopes to answer as I do not know what techniques to use, they are keeping me out of this part of the equation too much and I am trying to explain to them both why I need to be in it and what they need to give me – MetaGuru Sep 21 '11 at 18:22
  • @Ryan I'm asking what techniques are you using now? You don't specify this. You say you are asking. What does that mean? Unless you describe exactly what you are doing now, the kinds of questions you are asking, and how you are going about trying to get the information you need, I can't tell you what the next steps should be. – Thomas Owens Sep 21 '11 at 18:27
  • @ThomasOwens I'm literally saying things like 'I need more information for future products, things like requirements documents, etc. The problem I see is that they are not understanding what I am asking for, so I came here to look for common approaches. – MetaGuru Sep 21 '11 at 18:32
  • 2
    I guess its better than the 25-tabbed-excel-file spec that is all too common. – Morgan Herlocker Sep 21 '11 at 18:33
  • @ironcode, If given the choice I would choose the 25 tabbed chatty Excel document anyday over screenshots. – maple_shaft Sep 21 '11 at 18:55
  • @maple_shaft amen – MetaGuru Sep 21 '11 at 19:51
  • This question too specific to your situation. Perhaps you could rephrase it to make it more general -- strategies for dealing with vague/incomplete requirements. – Shane Wealti Sep 21 '11 at 20:08
  • 1
    It is not clear from your question if this is simply what your client has given you OR if this is what someone else on your team has produced as a result of their attempt at requirements capture. If it is the latter then you have a problem in your organization that might be pretty deep-seated. If it is the former, then you will need to practice some requirements gathering techniques as others are recommending. – Angelo Sep 22 '11 at 00:12
  • It's not clear to me from the question what your role actually is here. If the client has already mocked up a UI (presumably already based on known requirements) and you're just being paid to implement it, then what you probably want from them in the first instance is a proper UI spec, rather than a requirements doc. – calum_b Sep 22 '11 at 12:46
  • @Angelo it is kind of both, the client in the example is actually an internal member who lives in another state, and yes the requirement capture as far as I have seen in terms of physical content is this UI, so it's basically the latter... – MetaGuru Sep 22 '11 at 13:30
  • 1
    @Ryan, in that case then I hope the requirements guy can answer all the questions you'll have for him! Maybe he just expects that the you'll informally hash out the full requirements with him interactively? That's the optimistic scenario. – Angelo Sep 22 '11 at 14:51
  • @Angelo Yeah that's kinda the problem, we expect to go over things again later but then sometimes we take something as face value and obvious and don't think to ask about it, these are the things that end up coming back to bite us later. – MetaGuru Sep 23 '11 at 13:33

9 Answers9

19

Some other things you may need are:

  • Usecases or Workflow descriptions: Just because you know what a screen looks like, do you know how bad input is handled? Do you know how to transition between screens in ALL cases? You could include error handling here as well.

  • High-level system description: Something the explains what the whole system that these 25 screens are for, and what they do.

  • Data model: Is it possible to infer a data model from these screens? Is there a data model that must be used or are you free to design your own to get the job done?

  • Technical requirements: Are the specific technoligies that must be used because of licencing or for integration reasons?

  • Performance requirements: If there's a search screen, is there an expectation of what can be searched and how fast the response should be? What about responses for other types of actions? Can or should some of them be asynchronous (user submits job and comes back later)?

  • Security requirements: Does the application store potentially sensitive/personal data and if so, what kinds of data and what must be done to keep it secure? Do you need to meet some level of compliance (like PCI compliance for doing credit card payments)?

Also, is there any special business domain knowledge that you may need them to assist you on? Some industries such as insurance, banking, medical health records, etc... have all sorts of complex business logic. Such projects shouldn't be attempted without the help of a business analyst who knows that domain. But if it's just a shopping cart/info site for generic widgets, then you may not need such a team member.

FrustratedWithFormsDesigner
  • 46,105
  • 7
  • 126
  • 176
  • 1
    I don't know if you did it on purpose but this list is even in order of importance, with use cases and a high level system description (did they at least label the mockup screens?) being by far the most important things. I don't know if security requirements make sense to ask for thpugh. It seems to me like you as a developer should have a much better grasp of what security is needed to support their use cases, so you should decide on security requirements from the use cases and then inform the client. – jhocking Sep 22 '11 at 12:06
10

How to get people to understand that UI mocks aren't enough to create a working program:

I would handle this with an analogy. Since I'm a bit of a car nut, I'm going that route.

"Pretend I know nothing about cars. You hand me a few photos of a Ferrari. A couple from the outside and one from inside the car (taken from the driver seat so I can see the controls for the car). Now you ask me to build you a Ferrari. I come back with a thing that looks like the pictures and has all the controls. Unfortunately, those controls aren't hooked up to anything because (since I know nothing about cars) I don't know what those controls should do. I can't even make a guess because I don't even know what cars are supposed to do. So then we have a conversation like this:

"So what does a Ferrari do?" "It allows me to move myself from one point to another quickly." "OK. so what does this circle thing do?" "Oh, that's the steering wheel. By turning it, you can change which way the wheels on the outside of the car point. This will change which way the car moves." "OK, and what about this pedal thing?" "That's the gas pedal. It makes the engine go faster which makes the car go faster." ... a few minutes later ... "Ok, so what kind of engine does it need? I've done some research and I've found engines for golf carts and some for sports cars. Which should I use?" ... etc. ..."

Then you can explain the analogy. Handing the developers mocks of screens only tells them what it looks like, not what it does. Developers need to know what problem the program solves or how it will be used (like knowing what a car does makes it easier to design the car and take educated guesses about what things should do). They need to know what kinds of things they are expected to use (ie. the golf cart engine vs. the sports car engine) and what other non-UI requirements there are (car should go fast).

Things I would ask for:

General / High level problem description

Use cases / user stories

Performance Requirements

Required technologies / platform (Windows, Linux, Web)

Everything FrustratedWithForms has in his answer

Becuzz
  • 4,815
  • 1
  • 21
  • 27
  • 1
    +1 for the great analogy, although I'm not sure that's really the best way to communicate with a client. I'll be telling that to my non-technical friends to help explain what I do, but for a client that may be a little patronizing. – jhocking Sep 21 '11 at 19:15
  • @jhocking I completely agree that using that analogy is not the way to communicate to a client. I made the assumption that the mocks came from someone else in your company that already talked to the client. If you have to communicate this to a client, just explain that the mocks show you what it looks like but tells you very little about what it does (any information you get from the mock is a guess at best). They need to tell you more about what you are making. You just need to find a good way of asking and communicating that. – Becuzz Sep 21 '11 at 20:51
5

Something to the effect of 80% of development effort goes towards 20% of fringe use cases. Screenshots will not tell you about use cases thus you will be in the dark for 80% of your active development.

It is good that you are trying to figure out more and trying to communicate how important it is for the client to be more involved in the project requirements, however if they don't do this then they are setting up the project for failure, and that isn't your fault.

The majority of software projects fail because the client is not involved enough in the software development process. This isn't a new problem and it certainly isn't a mystery to why software projects fail but it continually happens over and over in the industry because of situations like this.

You can't just toss a trickle of information over a wall and expect to get back all of your hopes and dreams in the form of a software package. Software development just doesn't work this way. Whether you are an Agile or Waterfall shop, solid client direction is necessary to the success or failure of a project.

maple_shaft
  • 26,401
  • 11
  • 57
  • 131
  • 2
    "You can't just toss a trickle of information over a wall and expect to get back all of your hopes and dreams in the form of a software package" I love this sentence and I am so stealing it. – HLGEM Sep 21 '11 at 20:11
  • @HLGEM, Take it, it's yours! – maple_shaft Sep 21 '11 at 22:02
4

One thing that people seem to forget to ask, is what is the data going to be used for after it is input? Do you need reports? Do you need to generate a packing slip and send to the warehouse for shipping, etc. If data is used to make managment decision and reporting is needed, then that can change the database design. It can also add a serious amount of time to development depending on the complexity of reports.

You also need to make sure there is a path for each possible decision. So if something requires managment approval - then what do you do if is disapproved as well as what do you do if it is approved. If it is not approved or disapproved in X amount of time, then what happens to it? If they select a product and it is out of stock, what happens to the order? Those kinds of questions.

You also need to know if there are specific limits on what data should be put into each field. Are there required values. Where are you goign to get them from? How will they be updated? You need to know how to handle errors. You need to know if the database needs to have auditing or if you need to be able to recreate data from a historical perpective (back to those pesky reports).

Another thing I see happening is that applications may be designed just get to the release with no consideration of how the data will be maintained afterwards. Do you need an admin page to make sure that they can update their lists of required values? Do you need to send data back and forth to other systems. How are you going to get the initial data into the database?

HLGEM
  • 28,709
  • 4
  • 67
  • 116
3

Personally, I would ask for a half-day to day-long meeting with the client to walk through their UI design and their goals and make sure everything aligned.

Wyatt Barnett
  • 20,685
  • 50
  • 69
2

Start simple. Get them to understand that with the information you've been given, none of those screens would do anything. No details about use cases, bad input behaviour and so on. It just won't work. Explaining a blunt generalisation is easier than explaining details, because the point can't get lost. Trying to give them a more complicated justification for why screen mockups isn't enough gives them the opportunity to quibble your definitions instead of acknowledging the problem. Ask them to imagine that the back-end developer didn't speak English (or whatever language the screens are presented in). Then ask how different this situation is to a developer who has no knowledge at all of their business processes. Then build up to the more realistic example of yourselves, who have some knowledge, but are justified in believing that it isn't appropriate to decide their business logic for them.

Tom W
  • 316
  • 1
  • 7
2

People who haven't developed software don't know what software developers need to know. They can't be expected to produce requirements specifications and use cases on their own. You need to apply requirements elicitation techniques to get the information that you need to know. Work with the client (and hopefully a sample of users from various roles) to determine what they need or want. Common techniques for this are interviews and/or user observation, identifying use cases and user stories, and prototyping.

I would highly recommend applying iterative and incremental development techniques in this instance, since you have vague, incomplete, or poorly understood requirements. Look at the various agile methodologies along with the Spiral Model for addressing lifecycle planning.

Start by obtaining the business objective driving the development of this software. Interview the client and users, and if you can, watch them at work. Try to determine what problem they are trying to solve. See what tools they are currently using and how they use them so that you can improve on their current way of doing things. Use this opportunity to learn the domain and its language - it will become infinitely easier to communicate if the software developers and client/users all speak the same language (and don't expect the client/users to speak in software terms).

Once you understand what the objectives are, you can begin to work with the UI design mockups that you have and "reverse engineer" use cases and user stories from them based on how various screens fit together. The user story format would probably work out well to deal with a non-technical audience. The format of As a <user type>, I want to <action> so that <reason> works out in terms of getting developers and clients/users speaking the same language. Once you can get a start on the user stories, I would adopt a prototyping approach to development.

I think that I would approach this with the use of prototyping. You could approach this from either an evolutionary prototyping or throwaway prototyping perspective, but I would consider an evolutionary prototyping approach first. Start with the user stories that you are most comfortable with and have validated, and begin to implement them. As you implement them, get feedback from the customer and develop new user stories, use cases, and resolve misunderstandings.

Also, don't think about this as "implementing a user interface with features under it". Instead, think of it as thin vertical slices. Don't implement all of the user interface at once and then worry about features. Instead, use the user interface mockups to identify features and other requirements, and then implement a vertical slice from the UI down to the business logic and data storage. Repeat this for every vertical slice. You should also feel free to make suggestions to improve the UI based on the requirements and usability principles.

I would recommend reading two books by Karl Wiegers - Software Requirements and More About Software Requirements. I think these will help you out with requirements engineering and best practices in this area.

Community
  • 1
Thomas Owens
  • 79,623
  • 18
  • 192
  • 283
  • 4
    Just remember if you prototype, never make the user interface look polished and finished, they will think you are done with the coding if the screen looks finsihed. – HLGEM Sep 21 '11 at 20:23
  • @HLGEM Very true, very true. In fact, I'm pretty sure I've given that advice on this site before. – Thomas Owens Sep 21 '11 at 20:24
1

Well, this is an embarrassingly obvious starting reference, but Wikipedia might be a place for you and the users to start out. The fact that there is an entry about this stuff might help convince them that this is a real issue, not you being a pain.

More specifically, are you just baffled about what the application does, even after going over the mock-ups? If so, admit it, and try to explain that you have no idea what data each form should display, or where it would come from, is it from other screens or external data?

If you have some idea, try to come up with examples of things that you don't know how to do ("will the list of templates to select be one global list or are any of them by User, or something else? If it's not by User should I let two people edit it at once? What should the UI show if someone else is editing it? Is there a screen for that? Once someone has used a template for whatever templates are used for and then the template gets edited should that change be propagated to the thing they made with the template?").

Make it clear that with your present level of knowledge you will need to have questions answered approximately every 90 seconds for the remainder of the development cycle, and that much of the time you will be unable to keep working until you get an answer. The goal should be to make it clear why having some kind of process will make it all easier. Also mention that Q.A. is going to need the same information you do, so it will be easier to write it all down so it's available for everyone and nobody forgets anything.

It might help to mention that some of the code you write affects more than one screen at a time, so if you got as many answers up front as possible it might make it easier to write that code appropriately and not have to change it later.

If you still can't get requirements and you really don't know how to proceed, send out emails every time you need more information (i.e., requirements), and if you can't continue working without that information, state clearly that you are, unfortunately, unable to continue working, because the code you need to write will be very different depending on the answer(s) to your question(s). Don't complain, just very professionally let them know that you can't write the program until you know what it should do.

psr
  • 12,846
  • 5
  • 39
  • 67
0

You need to know the limits and ranges for each field in the application. For example, if the field is phone number, do they expect you to handle +1? Which fields are required? What do they want the application to do if the user types "abc" in the phone # field? Are all 25 screens in the order that all users must proceed?

Otherwise, just create everything as text fields and you are done! Wanna bet that will go over like a lead balloon?

SnoopDougieDoug
  • 1,947
  • 12
  • 8