Project Lamenting and User-Role-Centric Solution

For those of you who know about my new project, I've been so damn busy working on it. This client basically wants me to come up with all the business logic and specifications of what SHE wants, but DOESN'T tell me what SHE wants, so therefore I have to predict and be a fortune-teller to come up with something that SHE'S expecting, because she herself doesn't know what SHE'S wants the solution to do.

Simply fantastic, lamenting on this crappy project. I'm going to charge her for the consultation! Furthermore, I wasn't there during the meeting with the client to dig out information from her, and pick out everything out of her brains.

So anyway, here's what I've been researching and doing for the past few days.

I finally realised when creating a solution, one MUST think about the person using the solution itself. Trying to explain this method to my friend(s), who are in on the same project as me, made me realise the importance of a User-Role-Centric Solution. While coming up with the User-Role profiles, I realised a lot of unseen features appear that's not realised during the so-called "feature-creation" phase, which was done BEFORE creating this User-Role profile. Which was not supposed to be the case. *DEVELOPERS*

Anyway, creating a user-role profile is basically as simple as this. Determine who's going to use the solution. For example, in my case, we came up with 4 user-roles. The "General Person", the "Student", the "Teacher", the "Admin Staff". From this, I think you'll have a rough idea what the type of business this company I'm doing this project for are doing.

The question to ask when figuring out what user-roles there are is simply,
Who will use this solution?

So then, here are a few questions you'll ask yourself about each user-role.
1) Who are the people who falls into this category?
2) What does the person expect to accomplish with this solution?
3) What does the person need to have to use this solution?
4) Is there any problems with the current solution that can be solved with our solution?
5) Is there any forms of information communication between another user-role? What are they?
6) What are the tasks that the person can do with this solution?

Basically these are the few questions that one would ask the client, but apparently there wasn't a chance to do that for my case. Therefore I had to ask myself, and my other friends this question, and see what we can come up with.

In actual fact, we realised that when comparing with our original feature-list module-seperated format, which isn't entirely non-valid and still useable in the proposal under the section "Scope of the Project" and "Solutions Concepts", that we actually came up with more features that we didn't think of in the feature-list, and removed quite a fair bit of features that weren't needed and quite redundant. Which was good, in a sense that now the entire solution was based on "what the person is able to do with the solution", instead of "what this solution can do for the person". There are subtle differences, but when you actually think about it, your entire specification list simply changes and morphs into an almost totally different style. WHICH IS A GOOD THING(tm). So there and then, things start to change.

And I hope you guys also follow this way of thinking, instead of plunging down into feature-list.

Cheerios. Till next time.