Identifying requirements WUCM 1 1 Requirements engineering Requirements

Identifying requirements WUCM 1 1

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

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 WUCM 1 3

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 WUCM 1 4

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) WUCM 1 5

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

Roles • Owners • Stakeholders • Audience • Developers • Content providers • Managers WUCM 1 7

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? – – – – – WUCM 1 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? … 8

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? WUCM 1 9

Content requirements issues • Volume of data • ‘Churn’ of data – Significant impact on both hardware and software – It is important to get an estimate for: • • – 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 files average size of files database size total size of the web space • Number of ‘hits’ – Estimates will feed the capacity questions – Estimate the rate of growth of data to be served: feeds the scalability requirement WUCM 1 – For a new site: based on hope and expectation – For an existing site: collect data and consciously feed it into ongoing management is vital 10

Requirements should (ideally) be: • Well-defined • Measurable and testable – 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 WUCM 1 – Needs to be a way of determining whether the requirement has been fulfilled, especially if your fee is contingent on acceptance! 11