"shouldn't I build a blueprint a software company could use to directly build the plattform?""Isn't focusing solely on User Stories letting the software company a little bit too much freedom regarding design?"In response, to be clear; of course you can design your interface, you can even design your database schema, both of those activities are useful and provide a basis for starting the project. BUT neither are sufficient to bring the project to market nor are they likely to be retained if you actually produce the project.
"I think I need to describe the processes between differrent modules, how do I do this with just User cases?"
"Where can I define the database structure and security issues?"
Why? Because you hire specialists to do design for you. The thing you bring is your judgement, appreciation for use and usability, the specialised domain knowledge you possess, your commitment to the project, your access to financial resources or gateway into a market etc.
In my opinion you shouldn't even be thinking in terms of modules, database structure or security solutions. Although you should be conscious of the need for all of them to be present or resolved.
Unless of course you are the developer.
As a product manager or project leader for development, at some stage you are going to have to capture basic requirements (look back to this post).
But be careful you don't stray into specifying the system design!
Relax, the people you hire to do the development should have the freedom to offer the best design they can. Note that User Experience design is a separate specialisation from application architecture design. You should actually bring in different specialist skills for these two very distinct disciplines.
Relax, the people you hire to do the development should have the freedom to offer the best design they can. Note that User Experience design is a separate specialisation from application architecture design. You should actually bring in different specialist skills for these two very distinct disciplines.
The current practice for a system requirement is that it be:
* uniquely identifiable
* that it identifies the customer who requires it and why
* that it is expressed in goal driven terms rather than by specifying the implementation
* e.g. that you express it as a 'use case' using the storycard syntax "as a.. I want to.. so that.."
The same goes for functional and non-functional requirements. The main difference is in how testable they are.
Nearly everything else you produce for project planning and development is a design artifact not a requirement.
Reflect on this provocative opinion piece by Michael Schrage
"...have the wit and courage to ban requirements from every systems, process and innovation proposal made to top management. (Instead) Put use cases front and center in your value creation efforts."
blogs.hbr.org 12:31 PM Tuesday September 6, 2011
Also see this post on an underlying theory for requirements.
