What questions should you ask at the beginning of a project?
Regardless of the actual project, I usually ask the following questions.
- Scalability Requirements - How many users are we expecting?
Expressed as users per day. As part of that, however, we also need to consider spikes in traffic, and if we need to handle them. - Distribution Requirements - How many data centers are we going to run on? How many machines?
Numbers I want to hear: 1, a few, lots. - Security Requirements
- Authorization Requirements - Role based? Data driven? Dynamic? Rule based?
- Sensitive data - Do we store any? If so, how secure do we need to make it?
- Physical Deployment Layout - DMZ? Inside firewall? Different components in different zones?
- Regulatory Requirements - Are we required to meet some regulation? If so, what are the requirements in the regulation?
- Monitoring - How often? To whom?
It is not so much the answers that I am looking at, it is the discussion the posing this question that is the really interesting part.
Comments
I especially like this part:
"how secure do we need to make it?"
Too often, users give requirements like "The application must be secure." which is not a valid requirement. Unless the application is turned off and stored in an impenetrable vault.
Being willing to have a discussion about the amount of security that the data deserves, and the tradeoffs that means, is extremely important (assuming the customer cares about security at all, as financial institutions tend to).
Role based? Data driven? Dynamic? Role based?
You mentioned role based twice, How about to change second one to claim set or permission set based?
"The application must be secure" is not a requirement. If you're given something like that, that means they don't know how to write requirements and it's your job to communicate with the stakeholders and domain experts to define and clarify the requirements.
1 question: What does "Success" mean for this project?
2 question: What does "done" mean?
All other questions are refinements of those two. If you can't get them to define success you'll never satisfy the end-users.
I would definitely include in my questions at the beginning of a project if there are defined requirements. Also, have they budgeted time and money to engineer those requirements over the life of the project.
Other requirements-clarifying questions:
What is the vision for this project
What is the scope of this project
What is the charter for this project
What are the user classes and characteristics
Are there any design and implementation constraints (may include physical deployment and regulatory requirements)
What are the performance requirements
What are the safety requirements.
I also ask
"How quick is the turn around time with your billing department?"
:-)
Alex,
Role based and Rule based.
That was a typo.
Seems as though the contextual 'framework' you're searching for or wanting to discuss is pretty thoroughly covered by guys like J.D. Meir and others up on the MSDN Architecture site and at similar such sites at IBM. Meier's Arch Cheat Sheet isn't a bad starting point: http://tinyurl.com/6qfjc5
@Peter
Yeah buddy. Everything is a variation of these two criteria - unless you want to get sued or fired.
Too many times I have dealt with agile developers who vehemently do not want to ask themselves those kind of questions at the beginning of a project. I had the bad experience of such a project where it took the company about 4 months so that I could roughly figure out what was the overall goal of the system. I call this the 30,000 ft view of a project and I think this has an important place in agile because without a big fat document this is the next cheapest way of knowing what the hell is going on.
I do like Peter Richie's questions. And I may add something more, a colleague once said that until developers are made aware of what kind of reports the system is supposed to be able to produce then the data requirements are not clear enough.
First question I always ask is "do we really want to do this project". Second is "if we are going to take this project, who will be the experts and what knowledge will they provide".
I sure like Peter's questions, usual problem is to dive into technicalities without seeing the actual goals driving all things in the project, including technical ones.
ps: Sure, my definition "beginning of the project" goes a bit more earlier stages. Semantics.
"Scalability Requirements - How many users are we expecting? "
Asking how many users is an utterly useless measurement.
Does Starbucks give a rip about how many concurrent customers they have in their store?
No.
They're more concerned with "How many coffees do you sell per hour?" , "How many cappucinos do you sell per hour?", "How many iced drinks do you sell per hour?"
You know how long it takes to pour a coffee, make a cappucino or an iced drink. Using that, you know how many staff and how many espressor machines you should have to handle the volume.
The same with software. It is not about users. It's about things which happen.
Steve,
Users is a good metric because it force the project owner to think about this.
There is generally a direct correlation between the system load and the number of users.
Remember, I am not interested in NUMBERS, I care about what order of magnitude I need to deal with
How about Disaster recovery?