Related
I am a UI/UX designer. Currently I got interviewed for a post and now they’ve given me an Exercise where I am supposed to do a complete UI review/Audit/Analysis of their product. I need some suggestions to do the exercise:
What medium do you think is best for presenting such a review? A video, An audio with visuals, or a document highlighting issues in UI with callouts?
What are the key points that need to be covered in such a review?
So that I submit the best exercise and get selected. Thanks in advance.
First of all you should know that UI/UX is not my area of expertise. But I've been directly or indirectly involved with it enough to know that it's not an exact science. People will often debate about what is the best for the user. Just remember that two users themselves might not agree on something.
So what I think is important is that you genuinely take the role of a user, try using the product imagining a scenario where you want to accomplish something. If you do it right, you should have some feedback on what works well and what could be improved. It's your opinion, the important part is that you can back them up with common sense or valid arguments.
As for the medium, I'd say that you should choose the one that communicates your views the best. I'd rather read through well organized text than go through a poor video. You'd probably want to impress, so whatever you choose, do it well! If the UX design was documented upfront, you would normally use that as the basis for your review. So look up UX design tools, you might be able to use one of them.
If you have time, a background in UML modeling might be helpful, particularly the ICONIX methodology, which encourages exploring different "what if" scenarios, rather than just desiging for the standard (most common) path. Also assuming that you've already looked up online resources describing common best practices.
I'm a recent graduate who is looking to get a job doing user experience. Next week, I have a technical interview in which I will be given a website and will have to talk about its usability issues as well as come up with ways of improving the user experience. I feel I have the natural skills to do this and have been doing a fair amount of reading into the subject, but I would like some further advice on how to effectively critique different kinds of websites.
Does anybody have any suggestions of common faults I should look out for, or advice on ways of structuring my evaluation in order that it is relatively air-tight and I do not miss anything obvious?
As I've said before, I'm already doing a lot of reading and I realize that practice makes perfect. However, I'm hopeful that those that have long-term experience with this can help me by imparting their wisdom on gotchas, common issues, and what to look out for in a good/bad website.
Thanks in advance!
How easy navigation is
Whether a user can easily find what he needs without resorting to "search" function. Edge case: whether a user can find the search input field without using the browser's search function (Ctrl+F)?
Whether a site is browsable with images turned off
How many clicks it takes to accomplish an operation. Is that many really necessary?
Are the most important / frequently used features right there in front of the user?
Whether you communicate with the user in geek language
Whether you overwhelm the user with long literary texts where one or two words will suffice
Whether you use standard ideas in your UI. Do buttons, links and menus look like buttons, links and menus? Do they also work that way?
If UI is made up of a limited set of controls with consistent look and behavior? Or each page is unique and has to be learned from scratch?
Whether UI is accomplished with mostly 2-3 colors or uses different colors everywhere to look cool
Also check out the following questions:
Worst UI You’ve Ever Used
What are common UI misconceptions and annoyances?
Why is good UI design so hard for some Developers?
What is the best UI you’ve ever used?
As the other answers have talked a bit about usability I'll mention some things about accessibility (although good accessibility and usability go hand-in-hand).
First of all you need to get the usability correct - a site with poor usability will straight away mean that it will almost certainly also have poor accessibility. Make sure it makes sense, is easy to navigate and is structured meaningfully - for good accessibility that needs to be reflected in the markup as well as visually (so use headings correctly, use things like (strong) instead of (b)old, etc). Automated tools can provide some limited help with this.
Secondly make sure you use the various pieces of markup that are available which will enhance usability (e.g. alt tags on images). Automated tools are excellent for this.
Next if you're going to use technologies like javascript try to use progressive enhancement so that users without those technologies available still have a workable experience. Automated tools won't help much with this.
Finally don't get lured into thinking that an accessible website is a dull boring featureless one - for every user with visual difficulties there will be many more who have cognitive difficulties such as dyslexia. The aim is to make it engaging for everyone, not cripple it for a minority of users (who will likely also be penalised if you start slashing content - for example youtube is one of the most popular sites for blind users).
My thinking process :
See what's different. I mean ask yourself, "is this button here also done that way on youtube/google/basecamp/whatever has been proven good enought".
If it's not the case, I ask myself "does it make sense to do it differently?". If it doesn't make sense, then it shouldn't be that way to avoid confusing the user.
If it makes sense, I ask myself "If it's not obvious, what's the learning curve for the user?", always keeping in mind that "the user" is not IT.
Then I'd see if I can improve it. If I can't, maybe you can't improve it, so even if the control is not perfect it's good enough.
Finally ask yourself "what does the website wants the user to do?". Is it buying something? Subscribing? It's all about figuring out what's the objective. Then see if the website is oriented toward something aiming to complete this objective.
As well as practical ideas about usability problems, you might want to think what kind of process you'd use to do this work (and how it would fit into the company's development process). Would you start out with research? How would you present your analysis and feedback?
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 3 years ago.
Improve this question
I am a reasonably experienced C# developer (about 5 year experience) that has recently been put in charge of my first development team as technical lead (varying between 3-5 other developers). Over the last 4 months in this role, one dilemma that keeps arising is trying to find the right degree of sharing awareness of the communication that goes on between the project manager, account manager, clients, designers, CEO and myself (especially via emails).
On the one hand, I know the more awareness each developer has of the overall direction of the project, the better they can understand the scope that their particular functionality has in the big picture.
However on the other hand, a lot of my time seems to be lost in the sea of emails between all the different stakeholders and managers, so I like to think that isolating the developers to just "what they need to do their current bit of work" will keep them free from interruptions.
I have considered just BCCing all the developers so they can filter these emails and essentially "opt in" to all the emails, but I'm concerned that some of the developers will just see this as extra noise to deal with. It may open the door to "too many cooks" if all the developers want to contribute to too many discussions. Yet on the other hand, other opinions can help me reach better decisions (i.e. House MD style).
Phew... so much to consider. Anyone have some wise guidance in this area?
Answering late, but still believe there is something to add to the superb advice given so far. To answer your question we need to go a level higher, hence the long response.
You’ve been made a tech lead responsible for team and although many aspects of your everyday job might seem to resemble your dev days the way you need to go about them has changed. In software development environment there is usually not that much of a tangible change when you appointed a tech lead (you’re probably still seating at the same desk, wearing the same outfit) as opposed to becoming a foreman on construction site or a factory. The flattering change though is that you now get invited into all these meeting and start getting all these e-mails and phone calls from people outside the dev team.
The lack of tangible change might trick your mind into thinking that you just need to keep treating your job mostly the same. This is not the case and you need to be conscious about your actions and re-actions in the new capacity. It might seem you’re now a bit “more respected” externally and you might be inclined to share some of that “respect” coming your way internally, play a bit of democracy and generally be fair.
Well, this is not that much about fairness or respect, the new job is to:
Direct the dev team (mostly by personal example and creating imagery depicting the goal).
Be an abstraction layer between the team and other organisational units.
Pretty much like in programming you often create an abstraction layer to encapsulate and hide complexity, the same happens in organisations. You’re the layer, the interface that has to encapsulate the dev team. And any good encapsulation from an outsider point of view:
Hides inner complexity that is not relevant to the task at hand (such as concrete implementation of an algorithm) from the outside observer.
Makes things that could affect the outside user explicit (exceptions that can be thrown, any limitations and constraints etc).
Always gives meaningful feedback.
Acts consistently.
These principles are equally applicable to the team’s outward communication. It’s not an easy task to follow these principles; actually it involves a lot of concrete work, such as deciding what details are internal and what facts need to be communicated and when, how the feedback needs to be best structured and be presented in a consistent manner and who should be notified externally of what, and who needs to followed up and when. This is a lot of work, even if some of it seems to be just trivial admin.
Now to internal, inward communication. One way is to broadcast. But it clogs the internal network and everyone has to spend their time on deciding whether the communication bears any relevance to them. It is like having a very generic algorithm that regardless of input always does the exact same amount of work. It’s sure possible, but why would you want to do that? A more efficient way is obviously to adjust processing depending on the input and here it has to be someone’s job to make a decision how the team should go about something, to dispatch, or convert the input:
Decide what sequence of actions needs to be taken,
or just acknowledge and store for future reference,
or follow up,
or put an issue off for a later review and then make sure it is reviewed and fed back into the decision-making loop.
This is not a small job either and someone has to do it. Obviously now it’s your job to manage the outward and inward communication, and you have to spend some of your brain’s processing power to do it well, so no one else has to and devs can concentrate on their tasks.
There are some other good reasons for not CC-ing or BCC-ing everyone regardless of your job title:
TO means “take action”, CC — “take note for future reference”, BCC — “eavesdrop or mass mail”. You should be careful when you use one or another e-mailing a group of people:
E-mailing a single person is a straight forward “TO”, when E-mailing a group of people only “TO” these who you need to take action (including a simple acknowledgement). This is default meaning, in any other case explicitly tell them what is expected (i.e. FYI, no action needed etc).
CC only these who you want to take note of the information for the future reference. If you expect a number of e-mails to go back and forth before an agreement is reached or issue is resolved don’t “CC”, it’s best to send a summary confirmation later to other parties that need to be notified. Besides saving everyone’s time and avoiding misinterpretation due to someone taking note of a non-final communication that will help make exchange more personal, flow more naturally, and reduce formalism and red-tape. Often CC-d e-mails treated formally and this isn’t always a good thing (but sometimes exactly what you want).
Using BCC is almost never ok. The knowledge of someone eavesdropping on your conversations if come to light will easily ruin your trustworthiness. It is simply a question of “when”. And should your team worry then that you might be BCC-ing their conversations to someone else? Mass mailing through BCC in most cases is also wrong, it creates an impression that e-mail is specifically addressed to the recipient.
Forwarding, CC-ing and BCC-ing require little effort, but multiply noise and dilutes signal. It is worth to give some thought to what exactly you need a person to do and what they should know to act on your communication before composing it.
Some conversations are best taken completely "off line" (phone or better still face-to-face), because it gives you more room for maneveour. Broadcasting or formalising in writting is just like putting yourself into a corner. You can always confirm in writing latter.
Moving to the second part of a tech lead responsibility (directing the team through personal example and imagery depicting the goal). To accomplish that you don’t need to pass on to the team every single piece of information that happen to end in your inbox. You have to create a story and any good story is an abstraction of real events that consists of only relevant and interesting detail for a particular audience. Creating this brief story on the basis of your everyday experience and judging what is relevant and interesting and then presenting it regularly to the team is also quite a job.
But don't forget that by directing the team and serving as abstraction layer you help developers and outside world to interact more efficiently, accomplish more and tackle greater complexity, the job has a point.
The engineering team needs to understand the business reasons of why they are asked to do things on a macro-level. The engineering team will gain understanding and motivation from this. But too much chatter is a no-no, as you note, part of your job is to filter, and part of that means not exposing them to tons of noise. Your developers likely have opinions and insights as to how to do particular things or why to pick particular technologies, and they should be fielded for their expertise in those areas.
Definitely don't create a culture of BCCing.
One option is to have separate mailing lists that interested parties can subscribe to, but of course, not all chatter will be on those lists.
And of course, a regular company meeting is a must. Let the engineering guys know why the business depends on delivery of a stable, complete product (or whatever the upcoming milestones require). 20 minutes, no slides, no bullshit is what works for me. Your team & situation may vary.
It sounds like you're technical so I would give you this advice: Follow Joel Spolsky's advice on what Program Managers do. Basically, try to isolate your developers as much as possible so they can be as productive as possible.
He just mentioned this briefly in this recent article, How to be a program manager, but he has gone into more depth on this topic before. Look through his past writings for more info:
Once the spec was finished and the development team got down to work, I had two responsibilities: resolving any questions that came up about the design, and talking to all the other teams so that the developers didn’t have to.
If you aren't technical then you need to select someone from your team to help with the design work and they will have to interface with the customer a little to figure out what the requirements are and what the best design is.
EDIT:
On Joel's home page there are two sections titled Tech Lead and Program Manager. Look at the articles there for some more info on program managers, especially Human Task Switches Considered Harmful.
I'd be using a Wiki, you don't want to add to the email storm, and your developers can also contribute and change things. It's also really useful for sharing documents, and if done well it will become self-supporting.
BTW Cut/Paste from email to wiki seems like an odd thing to have to do, does anyone know a lightwieght .Net wiki that I can email content too?
One way might be to not forward all those emails and once a week compile all the relevant information, design changes, and so forth into a weekly meeting. I definitely wouldn't send out a barrage of emails to the developers. Of course, if something critical is discussed, then that should be put to their attention. However, try for a weekly recap and discussion of relevant details.
I'm seeing this question one year after it's been posted, however I can add my experience with some specific data for my case. For 2-3 developers on the project, I mostly do one-on-ones. Lot of times I do this over the IM or phone since most of my team spends a lot of time in home office. Meeting from time to time is inevitable, mostly when project is starting (1-2 developer meetings tend to be enough to kick off reasonably complicated project), but as a rule, all communication with the rest of the company goes through me and developers get a digest. Only exception is when I connect developer directly with the user (not management!) to work out details of the project.
I tend to avoid regular meetings (weekly or daily) and schedule meetings only when at least two of these happen, in this order:
Important info comes in (depending on urgency this can wait up to a week)
Developers are in the office, preferably for other reasons (developer-to-developer meetings)
Client is available (not much choice there, but I try to do meetings and connect developers with single hands-on expert on the client's side later)
I need design advice (since I'm a technical lead, I'm responsible for most of the high-level architectural decisions)
For teams of 4-8 people (8 people usually means two teams) I found out that short 30-minute meeting roughly once a week is more then enough to keep everyone up to date. This, of course, is in addition to one-on-ones which I do daily for junior developer and about twice a week for senior developers.
For one-on-ones, I prefer that developers contact me when they're looking for more to do or when they're have questions on task they just started doing. This is also a great way for me to keep eye on how things are going without developers needing to think about keeping me up to date. I tend to avoid e-mail when IM is enough, otherwise switch to phone (when there's something to explain or discuss) and to e-mail when:
Customer reported bug via e-mail
There are a lot of important small details and developer will probably go through that e-mail a lot of times during implementation
There are also developer-to-developer meetings when they need to coordinate on something (for example, when Java and Javascript developer need to work out interface details).
This way of working means that I have to respond to IM as fast as possible, and that I usually deal with a lot of interruptions so that developers have to deal only with interruptions for me or other developers. Which is OK, since important part of my job is to make developers effective.
If I need peace for coding (and can afford it) I found that delegating client communication to non-technical project managers and even beta testers (who are much better with distractions than programmers).
Ask them what they'd prefer. I assume they would rather not be cc'd on every email and would opt for a short verbal update on a regular basis.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I want to avoid the situations when my developers do not share the common knowledge (solutions for the problems they encountered, cool tips, common mistakes, shortcuts for achieving particular goal, configuration issues, partial requirements, etc.) with each others. I'm taking about the situation when such lack of communication is accidental (a result of the misunderstanding or improper management) - I'm not thinking about the situations when developers deliberately keep the knowledge for themselves.
I believe that the following techniques are extremely useful to improve the information flow within the developers team:
XP pair programming - due to the knowledge exchange within the pair (and due to the regular pair mixing).
stand-up meetings - due to the occasion to tell the others on what you're working on and what problems you encountered.
trainings/presentations/coaching prepared by the lead-developers to the rest of the team/department.
"web 2.0 tools" - techie blogs for the company/department, dedicated twitter account of team leader, wiki's and stuff like that.
Any further ideas? What techniques do you use (or did you) in your company? How would you encourage developers to share the knowledge between themselves?
Trust.
You are allowed to 'seem stupid', but please ask if you don't know, or don't fully understand what I'm saying. And please tell me if I'm wrong (I didn't realize it because I'm equally stupid.)
I worked at one company where every Friday we had lunch meetings for developers. Management would provide food while developers had to share their knowledge; present some tool or technique one learned recently, or give a demo of a project you are working on, etc.
It wasn't restricted to the technologies that were being used by the team at that time, developers were encourage to learn new technologies and give a demo to the team.
And at my current job we have monthly IT group meeting, where sometimes developers from different teams demo off the projects they've been working on.
An internal twitter-esque utility. Maybe a wiki if you can get it to work, I personally find it a little too much. But twitter is different. "just added an extention method to escape a like clause in a rowfilter" and stuff like that.
Some people may find it a little overbearing, but a common location for utilities so you know where to look and string.CountOccurrences isn't scattered throughout the codebase.
I'll add a few more
Hire the right people - This is essential if you want to create a great dynamic (asocial people require a lot more effort)
Pre-mortem and post-mortem. We use the wiki for this, create a page for each of your projects, split it into section of recurring things (both goods and bad). At the end of each milestone, have the team meet to do a post-mortem. At the end of the project (or after a fix lenght of time), have project coordinator compile this into something easy to read for posterity (and put it on your wiki)
Daily stand-up are a must! You already said it, but I find it so helpful!
If you have multiple teams in the company, organize conference about one of their greatest achievements. If possible on a regular basis, even accros department, you would be surprised how artists can be interested into programmers work.
Lunch is a good time to share, in our company we have the president breakfast, project leads lunch, end of projects supper. I love them all, mix and match for greater results.
Offsite meeting with the whole company is great, we do it at least once a year (morning we present what's coming up in the futur, afternoon, is activities to learn about the projects)
Wikis are great, but beware of informations that can become false over time (this is a reccuring problem with any written informations)
A few more things to my mind:
Patterns & Practices meetings - These don't have to be every week but there should be some time devoted to where the team can discuss various outstanding questions and have concensus for things that may save a lot of people headaches.
Culture factor - Does the work place provide enough socializing to help the team gel or could some team-building exercises, e.g. an obstacle course or cooking together, be useful in getting some dynamics established. Is there a humility among developers so that there aren't big egos that can be a problem. Another factor here is to think about how you'd answer this: Would you go to a local pub and have a drink with your fellow teammates? If yes, then you have some good points here while if not, then there may be some investigation to do here.
Retrospective follow-up - How are ideas presented during retrospectives considered and implemented? How are meetings handled in general?
Demos within the team - If some story got finished and involved some big code points, then perhaps there should be a little demonstration of this for the team to see what was done and allow others to see what was done so that the knowledge does get spread around. This can dovetail with my first point in terms of being something that helps to further communication.
I'm a big proponent of working in pairs. It is a good way to transfer knowledge and keep communication lines open. Try mixing up the pairs for each project as well.
I've tried many approaches, and am a big fan of working in pairs on projects, as well as doing regular discussions or meetings with the team.
However, I've also found that the single best thing I can do is foster a culture of constant communication between the developers. I try to have all of my developers communicate with each other as they work - not even necessarily waiting until a weekly or monthly meeting.
For me, this is a little trickier as most of my developers are not in the same location, so we have a single XMPP chat room setup, and all of us are always logged in when we're working on the project. Some of the developers (including myself) will login during our off hours, as well.
I do the same with the people in my office - we tend to be a fairly quiet bunch, but I'm very open to having people interrupt each other with questions, or grab a chair and sit down to brainstorm at any time.
Part of why this works, though, is I try not to restrict the communication to the work at hand, or any specific project. My feeling is that people are going to talk about other, non-work related things, whether or not I foster that. I'd rather have the "water cooler" talk in an official channel, though, than outside.
This makes everybody feel more at ease to ask the questions that "seem obvious". Also, people ask questions continually, since they're right there, and used to talking to everybody. It's easy to ignore if needed, but also much easier to just throw out a general question and see if anybody has ideas without feeling like a pain, etc.
My experience is that the time lost due to interruption is much smaller than the time saved due to having a group that is always eager to help solve a problem at hand.
If you have a small enough team, using adequately SVN commit comments, and exploit them a tool that generates an RSS feed (like Trac for instance) can be an easy and efficient way to promote communication.
There are several requirements for this to work, which are quite easy to attain:
- commit frequently (that is good in itself, as it allows everybody to benefit from each programmer's local changes, and to identify problems early);
- use verbose comments (which is good to, as it allows to trace more easily what was changed, in case anything breaks down);
- ensure everybody actually reads (better even, keeps posted to, through an RSS reader) the feeds.
Of course, there is no way to "reply" to such comments, but if someone really needs to reply, it's probably between that person and the committer, so mail is usually enough.
An other useful tool is to ask each developer to, let's say, once a week, write a 10 or so bullet point list of recommendations for fellow coders, on a topic he/she is really familiar with.
Time.
Official
Getting out of your dusty office to clear your mind, really taking the time to go to a lecture or training, it all helps to spread knowledge.
It's also easy to budget: N developers go to meeting for T hours.
Unofficial
"On the job" training... The things you need for your specific job can only be taught by someone who knows the job.
In the current climate, under the current pressure (must ship now), no-one takes time to fully explain something. Only when people are relaxed, they are readyfor information sharing. People are relaxed when they have enough time.
Apart from that, you need to bump into some specific linker error before you really start thinking about it. Without the time to think, ask, read, you won't be able to get the knowledge. You can't postpone it to an official linker-training.
Way harder to budget: developer Mary asked developer Sophie about dynamic linkage for an hour and a half. The day after, she went back with some questions. Experienced developers will spend more time distributing, while younger will need more time learning.
no walls - Have all of your developers in one large, non-walled room - where everyone can see and talk with each other.
common goals - ensuring your team has a good understanding of goals INCLUDING the goal of self-improvement
rewarding - rewarding - even if nothing more then communication - reinforces what you are looking to accomplish
Socialization and common goal always encourages exchanege of information.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
How do you show your clients/employers that you understood their requirements?
What do you recommend to use? Use-Case diagrams? Flow-Charts? Data-Flow-Diagrams? Decision Trees?
I'm not really asking for a very detailed answer. Just something simple to help me communicate with the person who wrote the requirements and to see if both of you are on the same page.
I usually put together a PowerPoint deck fairly early in a project, giving a high-level overview of the project, along with some architectural diagrams (the simpler the better) and screen mockups/wireframes. Then I have a "kick-off" meeting for requirements review, and talk through the business problem and proposed solution.
I simply explain the requirements back in my own language, supplying my assumptions and adding in limitations.
The requirement may be "Button turns green when clicked"
I would ask "Ok, so when the user clicks on the button, the background color of the button turns green, but the text stays the same color?"
Basically prompting the person giving the requirements to explain how THEY envision it working.
My role has a lot of requirements gathering. The best way I find is a two pronged approach, talk through a PowerPoint presentation keeping it all simple and high level, and showing a Proof of Concept or a mock up. Walking and talking the customer through will see them responding with many "what if's" such as "Can I chance the colour?" this gives everyone a broad idea of what they are getting. If you can get something the users can touch and play with that works really well at uncovering the hidden what if.
Then, back this high level up with really detailed low level requirements. Spell out the dotted "i" and crossed "t". Get the users to read through and sign them before anything more than the POC is done. Generally word with a lot of screenshots works well.
Unless the users can bring you UML's and data flow charts, don't use them in anything the customer sees or signs. If it is signed by the customer and you had to regigg the back end to meet a "what if" you have to totally get everything resigned.
The final thing is to ensure that the customers can talk to you in their own words about their requirements and spell out what they are getting. One way to do this is to sit in on any middle management sell to higher management.
Don't try and bamboozle the customer, if they want something changed at the last minute, explain what the cost will be, in time and money, and ask them if this totally required. Doing this, will often stop people making trivial changes, and force them to think about why they want the change.
Requirements are getting what the customer needs from what they say they want.
Edit-
To the point about showing screenshots early- this sometimes requires a good PM to let the customer know the time scales and where everything is at. If the PM helps to set some decent time frames and expectations, the customers won't get excited. The good thing of POC and screenshots is people get an image of what it could be like and can often work that inside their minds.
If you want to avoid screenshots do a wire-frame look or use a whiteboard and 20 mins of drawing. Just remember to save the whiteboard as a photo before you whipe it.
Whiteboarding (and the good old OHP) can be a godsend to requirements gathering- developing a good clear style of drawing concepts can save hours in workshops.
Flow charts tend to confuse some non-technical people (ie clients), as well as data flow diagrams. Use Cases are good and understandable, as well as Business Requirement and Technical Requirement documentation, possible some sort of rough wireframe sketches.
It really depends wich requirements you're talking about.
Functionnal requirements? Maybe that UML is the rigth tool for. But I would prefer a test o test specifications
GUI requirements? Nothing beats a paper and a pencil.
Security requirements? By describing the limits of your security, you avoid unexpected deceptions.
Reliability requirements? Both testing mechannism, and software/hardware backup/recovery plan.
Other requirements: depends of your client.
But anyway, keep in mind, and explain to the client that requirement WILL change during the development phase and that it will always be a discussion and a compromise between cost and functionnality. Being honnest give more confidence to your customer.
I think that the best way to show that you really understand the client idea is to build prototypes.
By the way I was present in the last edition of the Requirements Engineering conference and in one of the workshops (MERE), Siemens was showing and interesting software based on composing a video of the client idea (it was for projects not limited to software) just to ensure that all the requirements are fully understood.
Any way, the thing is that some times a creative way to show them is better. Don't limit yourself to the standard diagrams.
I have had good experiences with creating a simple vocabulary, with terms from the domain and their meanings and relationships, and then go through it and make sure everybody agrees on everything.
Writing and discussing the vocabulary forces you to think, rather than just thinking that "we'll figure that out later".
It's no silver bullet, of course, and should be used along with other means such as a functional requirements specification and possibly a prototype.