1 / 26

Identifying requirements

Identifying requirements. 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

boggse
Download Presentation

Identifying requirements

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related