Comprehensive Guide to Requirements Engineering for Web Systems

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. Kotonya’s example • The system shall maintain records of all library materials, including books, serials, newspapers and magazines, video and audio tapes, reports, collections of transparencies, computer disks & CD-ROMs. • The system shall allow users to search for an item by author, title or ISBN. • The system’s user interface shall be implemented using a web browser. • The system shall support at least 20 transactions per second. • The system facilities which are available to public users shall be demonstrable in 10 minutes or less. • Can you spot any problems? WUCM1

4. Types of requirement • General requirements – such as 1 above, which set out in broad terms what the system should do. • Functional requirements – such as 2, which define part of the system’s functionality. • Non-Functional requirements – set out the tolerances, boundaries and standards needed to deliver the functions, e.g. ….. WUCM1

5. Non-functional requirements • Performance requirements • such as 4, which specify a minimum acceptable performance for the system • Availability requirements • significant in a web system with global access. Reliability? MTBF? Etc. • Security requirements • will be looked at in more detail later • what would these be in a library system? • Implementation requirements • such as 3, which state how the system must be implemented • Scalability requirements • what future growth in demand should be catered for • relevant for the library? • Usability requirements • such as 5, which specify the usability in a measurable way WUCM1

6. Application to web systems • Do the general requirements engineering points apply? • Is a web system special in any way? • Look in your other texts • Compare and note opinions WUCM1

7. Web system example • Web System for student option choice • Initial: • General requirements • Functional requirements • And some non-functional: • Implementation requirements • Performance requirements • Usability requirements WUCM1

8. Reasons for a website • Broad categories • To inform or educate • To entertain • To market, sell or persuade • Collect information • To stroke someone’s ego • … • Most websites serve more than one purpose • Most are designed to make money WUCM1

9. 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

10. Owners and stakeholders • Consider the University website • Servers sited in Mercantile House and James Watson Building • Who do you think are: • the owners? • the stakeholders? WUCM1

11. 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

12. 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

13. Informational site • Employees • especially for an Intranet • Students • finding courses/units • study information • Information seekers • The curious • Random browsing • e.g. from www.port.ac.uk WUCM1

14. Entertainment site • Generally younger people • Often sophisticated web users • Usually fans who want to be ‘up-to-date’ • Bells and whistles seen as a ‘plus’ • E.g. from www.disney.com WUCM1

15. Business site • Current customers • Potential customers • Your investors • Your sales force • Your competitors • E.g. from www.ibm.com WUCM1

16. Non-profit site • Activists • Donors • Information seekers • E.g. from www.aidsquilt.org/Newsite/ WUCM1

17. Ego site • Creator • Family and friends • E.g. from www.yaboogie.com/~julie/index.html WUCM1

18. 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

19. Capacity • Web server capacity planning is done before the system assembled • Web server tuning is done after going live • Offering a new service alters matters • A new motorway alters the traffic flows on which the size/route of the motorway was planned WUCM1

20. Capacity planning • It is vital to undertake some initial planning: • Do the sums based on your estimates • Get a view on expected webserver performance: • At the launch of the service • In the future • Unplanned growth is liable to throw up significant expense WUCM1

21. Capacity planning questions 1 • How many HTTP operations per unit time (httpops) do you expect? • HTTP is a connectionless protocol • Each item on the page is the result of a separate connection and request • The number of httpops is very much dependant on the time of day • E.g. typical Sprint NY NAP usage WUCM1

22. Capacity planning questions 2 • What is the purpose of the website? • Average httpops will be very different to peak for a web server offering teaching materials • Have you analysed your log files? • presupposes you have a web server up, but gives a wealth of statistics • Are the hits spread around the globe? • Are the hits spread in time? • Is there a diurnal periodicity? • Do you have access to a suitable range of log analysers? If not, should you acquire one? • How tolerant are your users? • What are your throughput and latency goals? • Should you try to satisfy 90% of requests for files under 10Kb in under 5 seconds or less? • Gives a concrete start point for planning • User perceptions of the speed of response of your site may be different to actual speed WUCM1

23. Capacity planning questions 3 • What is the average size of transferred files going to be? • Typical figures used to be about 10Kb • Impact of multimedia? • Will you be providing any streaming media? • Characteristics very different to standard web traffic. • Separate server? • Will the web pages spawn additional processes? • e.g. CGI scripts that query a database • Potentially generate considerable server load for little actual traffic • An external server may be the answer • What sort of scalability do you need? • New server to cope with an increase in traffic? WUCM1

24. Capacity planning questions 4 • How available does your site need to be? • Level of redundancy? • Mirror sites? • How much bandwidth do you need? • How much data will be transferred per second? • How fast a server do you need? • RAM and disk subsystem WUCM1

25. Conclusion • Greenberg (1999) asserts: • Be well-defined • Requirements must be well-defined and unambiguous so that it is possible to derive a design from it and base the customer’s acceptance on it being fulfilled • Be achievable • Requirements must be achievable using ordinary means unless extraordinary means are part of the requirements. • Be measurable and testable • There needs to be a way of determining whether the requirement has been fulfilled, especially if your fee is contingent on acceptance! WUCM1

26. Extra references • For a view on building applications (including requirements capture) see: • Conallen, J.Building Web Applications with UMLAddison Wesley, (1999)ISBN: 0201615770 (in Lib) • Powell, Thomas A.Web design : the complete reference. McGraw-Hill/Osborne, (2002)ISBN: 0072224428 (in Lib) • Dyson, P and Longshaw, AArchitecting Enterprise SolutionsWhiley, 2004ISBN: 0470856122 (in Lib) WUCM1