Initially, who is responsible to write the requirements for the developer, the ux designer or the manager? - what is the easiest way to write them? and how ? - and is that the right way to let the developer concludes the requirements form the design?
closed as not a real question by Jon White, ChrisF, Patrick McElhaney Dec 3 '11 at 18:46
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center. If this question can be reworded to fit the rules in the help center, please edit the question.
It depends on the sort of project, but typically, requirements gathering is the duty of the business analyst, answering to the project manager.
The project manager sets high-level goals for the deliverable - usually KPIs and definable success criteria. These will be aligned with the business objectives of the client - for example, to generate a particular amount of revenue from an e-commerce site, or serve a certain number of people in an identified demographic.
The business analyst looks at ways of fulfilling these criteria with the deliverable. He or she will begin analysing the business rules of the recipients - both users and any client staff who'll take the deliverable as an internal system. They'll look at how these business rules can best be mapped onto the application's own 'models' - the ways it arranges entities and events, and its own particular workflows.
A user experience designer's role at this point is to augment the BA's work by analyzing user models - the sorts of application models the users themselves are likely to expect (or at least will understand easily). In practice, it's entirely possible the BA and the UX designer is the same person (I'm told this is common with smaller projects at web agencies).
Now, how do we write the requirements? Again, it depends on context, but the analyst will often write a series of use cases to meet, and specify the expected behaviours of the application. He won't design any specific interfaces, but he will talk about user workflows and what kinds of 'application models' will cause users the least 'cognitive friction'. He'll negotiate this, along with practical matters of scalability and operational parameters, with the senior developer or dev team leader, who communicates what is and isn't reasonable within the budget and timeline set by the project manager. Once the parameters and limitations around the functionality and application model are set out, we can start designing specific interfaces and interactions.
That's how it's often done, anyway.
get requirements right. getting requirements spot on manages clients expectations.
They are the responsibility of everyone but the project manager will ultimately be responsible for getting them signed off by the client.
Requirements are reached through a period of continuous to and fro between client, devs, PMs and UX and will take a considerable amount of time to get right.
I strongly suggest prototyping to elucidate rough requirements back to the client. if you do the usual requirements gathering/wireframe/build/uat you will run into problems. Once you have a prototype that the client is happy with can you say you have a final list of requirements.
and read this workflow method post by the same guys http://www.newfangled.com/how_we_prototype