Introduction to Programming and Software Development CMPCD1017

1. Introduction to Programming and Software DevelopmentCMPCD1017 Session 2: Requirements Analysis and Specification

2. Content • Requirements Analysis and Specification • Functional Requirements • Data • Non-functional Requirements • Case Study • Requirements Analysis and Specification • A Design • The Code

3. Last Week • You were introduced to the concept of the ‘Software Development Process’. • Specifically the ‘Waterfall’ model. • This week and next, we will focus upon requirements analysis and the development of a requirements specification Requirements Analysis Design Code Test Software

4. Requirements Analysis • Capturing the Requirements • In order to build software you must first know what it is required to do. • The ‘iterative’ process models aim to do this interactively with the user, showing them a demo/mock-up of a system to aid in their understanding of what Information Technology (I.T.) can do for them and therefore decide what they think they need. • This is commonly referred to as a ‘soft systems’ scenario. • Some ‘customers’ (clients) will know exactly what they require and will be able to describe what they want in detail. It will be your job, as an analyst to translate their textual description into a technical ‘requirements specification. • This is commonly referred to as a ‘hard systems’ scenario. • It is this scenario that we will centre on.

5. Requirements Analysis • Capturing the Requirements • The most commonly used method for eliciting requirements from the customer is to conduct meetings or interviews. • Initial questions should really aim to find out the nature of the problem. • Detail about the current information system, whether it be paper based or not as well as the low level functioning and look and feel of a new system can then be dealt with in later meetings. • The aim is to gather ‘functional’ as well as ‘non-functional’ requirements so that a design for the new system can be devised.

6. Requirements Analysis • Customer - “I would like a stock control system that is reliable and user-friendly’ • Functional Requirements • ‘stock control’ • Non-functional Requirements • ‘reliable’ • ‘user-friendly’ • At this point we need more detail. • Essentially, as an analyst, if you are not sure about something or you begin to make assumptions about the requirements then you should ask more questions. • Unless otherwise stated, if a given requirements specification in this module has any ambiguities, then we would like you to ask a member of staff for more detail.

7. Requirements Analysis • Analyst – ‘What are the different types of user for the stock control system?’ • Customer – ‘A warehouse worker who logs the addition and removal of stock from the warehouse. A warehouse manager who enters ‘stock take’ figures in order to get a ‘stock’ report. A purchasing manager, who is allowed to query stock levels and add/remove types of stock and update their re-order levels.’

8. Requirements Analysis • Function Requirements • Stock Control • Warehouse Worker • Add stock • Remove stock • Warehouse Manager • Add actual stock levels • Produce ‘stock’ report • Purchasing manager • Add new type of stock • Remove a type of stock • Update re-order level

9. Requirements Analysis • We can see that as we ask more questions, our understanding of the required system increases and our requirements specification will contain more and more detail. • One important item that is missing so far is how ‘stock’ will be represented in the new system as the system will be ‘modelling’ a real-world warehouse and its workings: • Stock codes, descriptions, maximum possible quantities of a stock item, etc • As an software analyst you should always remember that the ‘model’ requires ‘data’ in order for it to be processed into information, e.g. stock report, and the data needs to be described precisely if the information is to be precise (correct) From the user/device /sub-system Data In Processing Information Out To the user/device /sub-system

10. An aside • Data • Numbers • Whole numbers – Integers • 12 • Fractions – Floating point • 12.23 • Alpha-numeric • Characters • ‘T’ • Strings of characters • ‘The quick brown fox..’ • Stock Record • Stock code – 6 character alpha-numeric string • Stock description – 25 character alpha-numeric string • System stock level – Integer, max value 9999 • Stock-take level – Integer, max value 9999 • and so on…..

11. Requirements Analysis • Non-Functional Requirements • ‘Reliability’ is a qualitative attribute of software that will be looked at in later modules. • For the purposes of this: • ‘Does it have to be as reliable as a nuclear power station cooling system?’ • ‘Will occasional system down-time be acceptable?’ • ‘Will a paper-based back-up system suffice during system down-time?’ • Here we will focus upon ‘user-friendly’ • Analyst – ‘What do you mean by user-friendly?’ • You should also be asking what the other users mean by ‘user-friendly’.

12. Requirements Analysis • Non-functional Requirements • It is common for the customer to know what they want the system to do (hard system scenario), but not necessarily be as decisive over the non-functional requirements, especially the user interface (soft system scenario). • The non-functional requirements may need to developed using a ‘prototyping’ approach in order to give the customer and their other ‘users’ a chance to give feedback and aid them in deciding upon an appropriate interface (or other non-functional attribute) of the proposed software. • In this case, a menu driven approach is probably the best starting point. • Whether it be graphical or text-based can be shown as prototypes.

13. Case Study • As a software developer you have been asked to engineer a small program that asks for a users name, year of birth and the current year. It is then to output ‘Hello name, you are approximately x years old.’

14. Case Study • The Functional Requirements • As a software developer you have been asked to engineer a small program that asks for a users name, year of birth and the current year. It is then to output ‘Hello name, you are approximately x years old.’ • Green – Data Input – ‘asks for’ • Name, Year of birth, Current year • Blue – Information Output • String of text containing: • “Hello ” • Name • “, you are approximately “ • X • “ years old” • Processing • How do we calculate X

15. Case Study • Functional Requirements • We don’t really need to ask the customer how ‘X’ is calculated as we can use our own common sense and derive • X = current year minus year of birth • But this is an assumption and we should ask if this is what they meant.

16. Case Study • Non-functional Requirements • For this case study, after asking the ‘customer’ about the user interface they have stated: • Text-based • Ask for data input politely • The final output should be two clear lines down from where the data was input

17. Case Study Start • Design • We now have a clear idea of what is required: • Get ‘Name’, ‘year of birth’ and ‘current year’ from user • Calculate X • Output age information User Input Calculate X ‘Age’ Age ‘X’ Info Output Finish

18. Case Study – Filename “session2.java” import java.util.*; public class session2 { public static void main(String[] args) { // Set-up data input and declare variables String name; int year_of_birth, current_year, x; Scanner data_input = new Scanner(System.in); // Get user's name System.out.print("Please enter your name: "); name = new String(data_input.next()); // Get user's year of birth System.out.print("Please enter your year of birth (YYYY): "); year_of_birth = data_input.nextInt(); // Get current year System.out.print("Please enter the current year (YYYY): "); current_year = data_input.nextInt();

19. Case Study – Filename “session2.java” // Calculate age x = current_year - year_of_birth; // Output the age System.out.printf("Hello %s, your approximate age is %d%n%n”, name, x); System.out.print(“Type 'OK' and press Return to continue: "); // Wait for the return key to be pressed name = new String(data_input.next()); } }