You will need to… Sort out your teams Know your assessment schedule Identify your personal project title Discover the core functionality Agree the shared components Document all meeting with your SCRUM log Create clear lines of communication Work together – don’t form cliques

Software tools… Some mechanism for sharing documents Google docs? You all have Office 365 accounts? GitHub? Visual Studio Online? Development environment Decide on architecture Front end – back end

Two deliverables to focus on Product Contract – what you plan to do Clearly state core functionality Why is the product needed? What components will be shared? Social impact study – identify topic Ethical review – cannot start project till this is approved Initial Deliverable Analysis and design documentation Class diagrams, use cases etc. Testing – how will you approach this Smoke and Mirrors Prototype

So where do you start? Once you know your project title and I have said it is suitable need to get to grips with the requirements Discuss with your team where the overlaps are Bounce ideas for how might the products work Use each other as test users Follow the strategies outlined in IMAT2204 last year

Role Play the Scenario Who what when where and why? (If you are not clear on any of these points then you must return to the client and find out.)

Create detailed written description The consultant sits at their desk with a stack of business cards and flyers. They pick up a business card and start to input the details into system. The first field they enter is the name of the company. While doing this the system looks up the company name to see if it is already on the system. The next field the user enters is the name of the contact. Whilst dong this, the list of contacts for that company is displayed such that if the contact is already on the system the user may move onto another business card. At this point the user should have the opportunity to update the details on the system should they note that some aspect has change e.g. address.

The Event Table Probably the most useful tools for digesting the problem Informs your use cases Informs your class diagram Don’t get hung up on it being right Better to add more events and discount them later Understanding will still be fuzzy at this stage of the game

Address Book Event Table SubjectVerbObjectResponse UserViewsAddress List Addresses are listed by the system UserFiltersAddress List Address list is filtered based on pattern UserAddsAddressAddress is added to the system UserUpdatesAddressAddress is updated on the system UserDeletesAddressAddress is deleted from the system SystemValidatesAddressAddress data is accepted or error is displayed

Identify Candidate Events from the Specification The consultant sits at their desk with a stack of business cards and flyers. They pick up a business card and start to input the details into system. The first field they enter is the name of the company. While doing this the system looks up the company name to see if it is already on the system. The next field the user enters is the name of the contact. Whilst dong this, the list of contacts for that company is displayed such that if the contact is already on the system the user may move onto another business card. At this point the user should have the opportunity to update the details on the system should they note that some aspect has change e.g. address.

Some Filtering Required Not events but still contain important information about the system “consultant sits at desk” “pick up a business card” Are these the same thing? “input the details” “enter the company name” “enter the name of the contact”

Identify the Verbs in the Event Table SubjectVerbObjectResponse UserViewsAddress List Addresses are listed by the system UserFiltersAddress List Address list is filtered based on pattern UserAddsAddressAddress is added to the system UserUpdatesAddressAddress is updated on the system UserDeletesAddressAddress is deleted from the system SystemValidatesAddressAddress data is accepted or error is displayed

This Informs the Selection of Use Cases

The Subject Column Identifies the Actors SubjectVerbObjectResponse UserViewsAddress List Addresses are listed by the system UserFiltersAddress List Address list is filtered based on pattern UserAddsAddressAddress is added to the system UserUpdatesAddressAddress is updated on the system UserDeletesAddressAddress is deleted from the system SystemValidatesAddressAddress data is accepted or error is displayed

Create Use Case Descriptions Use Case Name (Short two or three word name) List Addresses Use Case Description (Short description) The user views a list of addresses in the system Use Case Author(s) (Who wrote this) Matthew Dean Actor(s) (Who does this) User Locations (Where does this happen) On-line Primary pathway (What is the normal “happy path” for this use case?) List addresses User enters the system A list is displayed to the user at system start Alternate pathways (What other paths are there that are not the “happy path”?) There is no data in the system – a message is displayed saying so User applies filter A filtered list is displayed to the user User clears filter Full list is displayed to the user Exception pathways (What could possibly go wrong?) Database connection fails Error displayed to the user advising of connection problem

Documenting Use Case Diagrams Do not cram too much on one page Make sure they can be read without the aid of a microscope Keep them clear and simple