Requirement process includes two phases, requirement gathering and requirement developing. We combine them as a whole now. There’s not too much possible to separate them completely in our reality. There are two outputs from Requirement Process in my opinion. The first is the business domain model and the second is the specific requirement list. They are more formal description with some technological diagrams and terms. I don’t think it is a problem to understand them when I read some old documents of the product. The business domain model can gather the knowledge in the business domain and become the general language in the whole application lifecycle. Meanwhile the process of building business domain model can make all the involved persons, not just the development team, also including the marketing team, management and even the end users, understand the domain deeply and completely. The business domain model’s core is the top-level class diagram, the description and a term definition list. Sometimes it may include the business process diagram, state diagram and robustness diagram. I think Use Case is the best method of the requirement gathering and analyzing from my several years experience. But use case is too easy to learn and very difficult to master, so it is misused frequently. There are some points I think we should focus on. 1. About system scope The key factor of a successful developing process is to identify the system scope. Use Case technology provides two ways to ensure this. The first way is to define the right actors. For example, in the complex Use Case we often need to change the actor’s name two times or above as we understand the requirement deeper and deeper. The second way is to define the Pre-Condition in the Use Case specification. It will take our many minds to describe the right and exact Pre-Condition. 2.About scenario’s interactive flow The scenario’s interactive flow should become the central task in the requirement process. We can’t just list the steps in the scenario and we also should describe the system’s response. It maybe looks silly to write the system’s response at the beginning. But just this “silly” process can lead us to explore the flow branches and the more creative interactive UIs as soon as possible. 3.About user interface prototype UI prototype technology looks like to solve the requirement communication problems. But it is not the fact. If the UI prototype is the center of the discussion, communication and analyzing, there will be two severe results. The first is the discussion will be too detailed to ignore more important aspects. The second is the team will treat it as a final solution easily. In this situation, if the requirement team has not too much developing knowledge and UI engineering knowledge the solution may bring some big obstacles to the implement phase, or we may lose the chance to search better solution. There are some principles in using the UI prototype technology from my experience.
- UI prototype is just a “prototype” which can be discarded.
- In Requirement Process UI prototype can only be used in the place where the meaning is hard to be described with clarity by words or where the action has many complex operation branches.
- UI prototype can’t have the contents about the implement solutions as soon as possible.
- If possible the UI engineer can participate in the developing of UI prototype to increase the User Experience of the UI prototype.