Requirements. Project Work Tensu / Sten

Transcription

1 Requirements Project Work Tensu / Sten

2 Requirements gathering One source for ideas are competitors, or similar or look-alike existing applications available (even only components) Requirements may be compulsory / mandatory optional (would be good) dropped (not to be implemented now) All requirements could/should be put on priority order (note Scrum backlogs) A common agreed glossary may sometimes be a good tool

3 Requirements gathering during the project, 1 On sprint zero you try to gather all the requirements needed for your project You agree with customer about those You make iterations and show deliverables to customer You may re-define requirements and project goals with customer, during the iterations Customer, and group, may get new ideas during the project, and add or drop requirements Make sure you have the current requirements documented somewhere (e.g. product backlog)

4 Requirements gathering during the project, 2 Every requirement should have explanations to whom it was made (actor)? what? why? In tough projects requirements must be traceable (usually with requirements management tool) You should not add requirements or features just for fun or because you can KISS = keep it simple and straightforward

5 Requirements detailing Make sure (at the very beginning) that every group member understands WHAT is to be done, i.e. what the client/customer wants. Also find out WHY the client/customer wants what (s)he says. It helps if you understand why you are doing something, and just that way (and not the other way). The customer may also re-think about his/her business because of group s ideas

6 Requirements gathering, towards goal One analogy is parachute jumping; when you jump out of the plane, you see the goal (land target) as a small point, no details yet. When approaching surface, you will discover more and more details on the ground. You can also steer your landing (but not much). You may even see a better landing place, than the one you were aiming at the start of your jump. If you don't look down (ahead) and don't steer, you MAY get hurt

7 Weed out requirements from customer You have better ask your customer to write a list of his/her requirements. Then ask (s)he to order those by priority (the most important features first). You may agree with your customer e.g. that X first requirements will be done in any case (mandatory) (e.g.10) 10 next will be done if enough time (optional) The rest will be moved to version 1.1 (next project). Do not forget the power of diagrams! Some kind of Data Diagram (käsitekaavio) may be used (almost a Class Diagram ) Or Use Cases

8 Requirements will evolve and be refined At the beginning of a project requirements are usually vague/half baked Customer s project topic only gives the big picture (application/business area, environment, ) Requirements will evolve on the discussions and negotiations between customer and group Are there end-users available for comments? If customer doesn t know well what (s)he wants, show a GUI paper proto or mock-up or GUI prototype

9 From TIE and TIE courses Remember every kind of requirements: Functional, e.g. making calendar entries and synchronizing those with other devices Non-functional, e.g. user can change GUI colours, security issues Restrictions and limitations, e.g. C# must be used, must comply with customer s coding conventions. What kind of system does the competitor have?

10 A memo from first customer meeting

11 Requirements documentation Requirements should be documented on some way, e.g. for making test cases and acceptance, and for maintenance If errors or misunderstandings are found, requirements must be updated Requirements documentation that is not up-to-date is quite useless s are NOT suitable way of document requirements!

12 Documenting Requirements Remember to use exact definitions for requirements, such that are measurable and testable. NOT good text in Requirements are e.g. UI should be nice Response time should be short System should store big amount of data Application should be easy to use

13 Requirements Diagramming Do not forget the power of diagrams!

14 Customer Project Work Tensu / Sten

15 Customer is Always right! Don t argue, agree or don t show that you think differ The most important stakeholder of our project! So listen carefully what (s)he wants and says Listening and watching you! Customer is creating a picture of you as person and as IT professional Always having the final word! Visualize your understanding, show it customer and agree

16 When meet the customer Be prepared! Be polite! Be innovative! Be motivated! Show that you are there for the customer! Remember to make good memos! Take action points! Communicate clearly and precisely! First listen, then discuss and finally agree!