|
Functional specs can be a humongous trap. Don't prescribe solutions, describe the user's need, and develop the criteria must be met for the users to accept a particular solution. If you find yourself writing "the application will have a table/button/drop-down" stop yourself. Users don't need buttons and tables, they need the ability to enter and view comments (for example). Then for acceptance criteria, you might have "users should not be able to enter comments anonymously". The point is, if you jump straight from "we've met with the business to understand their needs" to "here's your specification code monkeys, get to steppin" you pigeon-hole the people who will actually be building the solution and obscure the core needs of the user (which leads to a bevy of problems, including misunderstand the spec). Just like you need buy-in from the business to build an application, you need buy-in on the solution from developers, or you will not end up with a quality application. In addition, unless you are perfect in designing a solution (no one is), the spec will require revision, which is just unnecessary work. Let the application itself be the true "living" document and use the acceptance criteria in combination with frequent business demos to make sure the application meets specification. Reading: http://www.boost.co.nz/blog/2010/09/user-stories/ http://www.boost.co.nz/blog/2010/09/acceptance-criteria/ Lord Of Texas fucked around with this message at 19:51 on Aug 23, 2014 |
#
¿
Aug 23, 2014 19:47
|
|
|
|
| # ¿ Apr 28, 2024 19:28 |
|