Identifying requirements

1. Identifying requirements WUCM1

2. Requirements engineering • Requirements elicitation • Consult with stakeholders • View system documents • Use domain knowledge • Undertake market studies • Requirements analysis • Tease out the detail • Requirements negotiation • Formal process with stakeholders • Decide on which to accept • Requirements validation • Check for consistency • Check for completeness WUCM1

3. Types of requirement • General requirements– which set out in broad terms what the system should do. • Functional requirements– which define part of the system’s functionality. • Non-functional requirements – set out the tolerances, boundaries and standards needed to deliver the functions WUCM1

4. Non-functional requirements • Performance requirements • specify a minimum acceptable performance for the system • Availability requirements • significant in a web system with global access. Reliability? MTBF? Etc. • Security requirements • specify who can and cannot do what • Implementation requirements • state how the system must be implemented • Scalability requirements • what future growth in demand should be catered for • Usability requirements • specify the usability in a measurable way WUCM1

5. Reasons for a website • Four broad reasons: • To inform or educate • To entertain • To market, sell or persuade • To stroke someone’s ego • … • Most websites serve more than one purpose • Most are designed to make money (directly or indirectly) WUCM1

6. Examples • To inform or educate • Universities, schools, colleges • Charitable foundations • Non-profit organisations • Government • Business • Political organisations • … • To entertain • Galleries and museums. • Magazines, E-Zines etc. • Media organisations • To market, sell or persuade • Businesses • Political organisations • Non-profit organisations • Universities, schools, colleges • Religious organisations • To stroke someone’s ego • Personal home pages • Opinion sites • Fanzines and fan clubs • Personal resumes/CVs • … WUCM1

7. Roles • Owners • Stakeholders • Audience • Developers • Content providers • Managers WUCM1

8. Who is your audience? • Why is your information needed? • Solve a problem? • Make someone feel good? • Get them involved? • Tell them something new? • Sell them something? • Teach them a new way to do something? • … • What do you want the user to do? • E-mail you? • Fill out an order form? • Phone you? • Complete a survey or application form? • Write a letter to someone? • Vote? • Join a mailing list? • Come back on a regular basis? • … WUCM1

9. Why know your audience? • Knowing your audience will colour many of your requirements • The non-functional ‘artistic’ website type requirements • The more technical server requirements • What balance of the two is needed? WUCM1

10. Contentrequirements issues • Volume of data • Significant impact on both hardware and software • It is important to get an estimate for: • number of files • average size of files • database size • total size of the web space • Estimates will feed the capacity questions • Estimate the rate of growth of data to be served: feeds the scalability requirement • ‘Churn’ of data • Measure of the proportion of the total web space changed per unit of time, e.g. hour, week • Need to back track through older versions of documents? • Number of ‘hits’ • For a new site: based on hope and expectation • For an existing site: collect data and consciously feed it into ongoing management is vital WUCM1

11. Requirements should (ideally) be: • Well-defined • Clear and unambiguous so that it is possible to derive a design from it that can gain the customer’s acceptance on it being fulfilled • Achievable • Doable using ordinary means unless extraordinary means are part of the requirements • Measurable and testable • Needs to be a way of determining whether the requirement has been fulfilled, especially if your fee is contingent on acceptance! WUCM1