EIS 610 Project Deliverable #1

You may work as an individual or in a group. You should have at least 5 user stories per group member.

Inception Phase (Project Kickoff)

The following artifacts from the inception phase must be complete and submitted as a Word or text document:

* Project Vision

This should be the vision from your story submission, so no fresh points. Penalty if not included.

* Project Boundaries (What I am not going to do)

This should establish the boundary conditions of your project. For example, you might say, it will not be an IOS native application.

I would expect multiple boundaries, not just one.

Be careful that this does not sound like a vision statement.

Have at least 5 boundaries.

* Requirements that are written as User Stories

Identify what you think is 90% of the user stories.

Each student needs to create 5 user stories.

User stories are written in the style of As a [type of user] I want [some goal] so I can [some reason]. Do not forget the so I can clause otherwise, there will be a penalty.

* Business Case and Initial Cost Estimate

Assign points to your user stories and use cases based on intuitive complexity.

Do a search for other similar existing software and note costs. (You can invent this)

List open source software that does a similar function and describe what is not suitable about it.

Make an arbitrary decision about how much each user story/ requirement point is going to cost in hours. For example, you may say each point costs 4 hours.

Then decide what your hour is worth and estimate the development cost.

Identify business risks for the project.

Identify the cost of tools and other equipment you will need. (you can invent this)

Make the Buy or build decision. Hint, you will decide to build. Based on 1 through 7 Why did you decide to build? (At least one small paragraph justifying why you decided to build)

Technical Risks

(These are technical 'things' we dont know how to do, but will need to know to write this program)

What skill will you need for this project but do not yet have?

These are things that could jeopardize the implementation of the software product.

These things make you nervous about accepting and implementing the project because you dont know how to do them.

Do not include things like the popularity of the product. That is a business risk.

Do not include things like staff leaving the project. You are the staff.

Do not include any generic risk mentioned in the text. These risks should be unique to you.

Non-functional requirements

Non-functional requirements are how a system is judged when it is complete. If a system is specified to be secure, specify a non-functional requirement indicating security. Remember, non-functional requirements can form the basis of functional requirements. These do not have to be written as user stories but can be.

Suggestions:

Security, special capabilities, usability, human factors

Reliability requirements (frequency of failure)

Performance (response times, throughput, storage usage)

Supportability (adaptability, maintainability, internationalization, configurability, etc.)

+ packaging, legal, deadlines, odd requirements, etc.

Note: You do not need something for each of these. You might not need any of these.

Glossary.

You must include a glossary of terms applicable to your project. (Domain-specific terms) For example, define the operation or reports if your project is an account application. (Posting, trial balance, etc.) This is not a catch-all for technical terms, so don't simply add a keyboard, mouse, CPU, for example.