cc20o7n software engineering 1 cc2007n software engineering 1 introduction to requirements...

CC20O7N Software Engineering 1

CC2007NCC2007NSoftware Engineering 1Software Engineering 1

Introduction to Requirements Engineering/Analysis


ContentsContents1. Introduction

2. Requirements engineering/analysis tasks

3. Systems modelling paradigms: 3.1 structured/conventional

3.2 object-oriented


IntroductionIntroduction• Requirements engineering helps software

engineers to better understand the problem they are to solve.

• Who does it? Software engineers (system analysts) and other project stakeholders e.g. managers, customers, end-users, etc.

• Why is it important? It is important to understand what the customer wants.


Introduction (cont.)Introduction (cont.)• What are the steps?

– Inception – Elicitation– Elaboration– Negotiation– Specification– Validation

• What is the work product? All project stakeholders should be provided with a written understanding of the problem e.g. user scenarios, functions and features lists, analysis models, etc.


Introduction (cont.)Introduction (cont.)

• How do I ensure that I’ve done it right? All work products are reviewed with the customer and end-users to ensure that what you have learned is what they really meant.

• Requirements engineering can be viewed as ‘a bridge to design and construction/implementation’.


Three Categories of RequirementsThree Categories of Requirements

• ‘Functional’ requirements - traditionally refer to WHAT the system must do.

• Non-functional requirements - aspects of the system that are concerned with HOW well it provides the functional requirements e.g. performance criteria, anticipated volumes of data, security considerations, etc (i.e. constraints).

• Usability requirements - to ensure that there is a good match between the system and both the users and the tasks they will undertake when using it.


UsabilityUsability• An attempt to qualify user-friendliness and can be

measured in four characteristics:– The physical and/or intellectual skill required to learn

the systems– The time required to become moderately efficient in

the use of the system– The net increase in productivity measured when the

system is used by someone who is moderately efficient

– A subjective assessment of users attitudes towards the systems.


Requirements Engineering TasksRequirements Engineering Tasks• Inception – a task that defines the scope and nature of the

problem

• Elicitation – a task that helps the customer to define WHAT is required

• Elaboration – basic requirements are refined and expanded. This task involves MODELLING

• Negotiation – ‘conflicting’ requirements must be ‘resolved’ and the following questions answered: – what are the priorities– what is essential– when is it required? – etc.


Requirements Engineering Tasks Requirements Engineering Tasks (cont.)(cont.)

• Specification – the problem is specified in some manner e.g. a specification can be a written document, a set of graphical models, a prototype, or any combination of these.

• Validation – the work products are assessed for quality to ensure that requirements are unambiguous, complete, consistent, etc.


InceptionInception

• Identifying the Stakeholders – people who benefit in a direct or indirect way from the system which is being developed.

• Recognizing Multiple Viewpoints (of stakeholders)• Working towards Collaboration – to identify requirements

on which all stakeholders agree and requirements causing some ‘conflicts’ among stakeholders.

• First questions: to identify stakeholders, to identify measurable benefits of the system.

• Next questions: to gain a better understanding of the problem.


ElicitationElicitation• Before requirements can be analysed, modelled, or

specified they must be gathered through an elicitation process.

• There are many ‘traditional’ requirements elicitation (or fact finding) techniques: background reading, interviewing, observation, document sampling, questionnaires. They have their advantages and disadvantages (see below)

• There are also some ‘modern’ requirements elicitation techniques e.g. JAD (Joint Application Design) sessions, Collaborative Requirements Gathering (see Pressman) etc.


Joint Application Design (JAD)Joint Application Design (JAD)

• JAD - an information gathering technique that allows the project team, users, and management to work together to identify requirements.

• JAD is a structured process in which 10 to 20 users meet together under the direction of a facilitator skilled in JAD techniques.

• One or two scribes assist the facilitator by recording notes, making copies etc.


JAD (cont.)JAD (cont.)

• JAD sessions can run from as little as half a day to several weeks

• JAD sessions are usually designed and structured using the same principles as interviews, follow a formal agenda and have ground rules that define appropriate behaviour

• The JAD facilitator performs three key functions:– to ensure that the group sticks to the agenda– to help the group to understand the technical terms and

jargon– to record the group’s input on a public display area

• The facilitator must remain neutral at all times and simply help the group through the process.


Background ReadingBackground Reading

• Suitable sources of information:– company reports– charts– policy manuals– job descriptions– documentation of existing systems– etc.


Background ReadingBackground ReadingAdvantages and DisadvantagesAdvantages and Disadvantages

• It helps to get an understanding of the organization BEFORE meeting the people who work there. (+)

• It allows to prepare for other types of fact finding exercises. (+)

• The documentation may provide formally defined requirements for the current system. (+)

• written documents often do not match up to reality. (e.g. out of date, reflect ‘theory’ rather than practice) (-)


InterviewingInterviewing

• A system analysis interview is a STRUCTURED meeting between the analyst and a member of staff of the organization being investigated.

• The degree of structure may vary from a fixed set of questions to open-ended covering certain topics.

• A series of interviews can range across different areas of the interviewee’s work or to investigate that work in more and more detail.


InterviewingInterviewingAdvantages and DisadvantagesAdvantages and Disadvantages

• Personal contact allows the analyst to be responsive and adapt to what the user/sponsor says. (++)

• Probing in greater depth about the user’s work (+)• If the interviewee has nothing to say, the interview can be

terminated (+)• Time-consuming and costly (-)• It requires the analyst to work after the meeting (-)• Subject to bias if the interviewer has a closed mind about

the problem (-)


ObservationObservation• Watching people carrying their work in a natural

setting allows to observe the normal aspects of a job as well as exceptional situations (which the system will have to cope with!).

• Observation also allows the analyst to see what information people use to carry out their jobs (is all the necessary information available, at hand?)

• Observation can provide quantitative data about typical times to perform a task, task duration etc.


ObservationObservationAdvantages and DisadvantagesAdvantages and Disadvantages

• It provides first hand experience of the current system operation. (+)

• Data collected in real time, so have a high level of validity. (+)

• Can be used to verify information from other sources. (+)• Most people do not like being observed and are likely to

behave differently. (-)• There may be logistical problems for the analyst ( e.g. if

staff to be observed work shifts, etc).• There may also be ethical problems if sensitive private or

personal data are involved.


Document SamplingDocument Sampling

• Document sampling can be used in two different ways:– copies of blank and completed documents are used

to determine the data and information used by staff, input to and outputs from processes they carry out

– statistical analysis of documents will help to estimate volumes of data to be held, to be input, and output.


Document SamplingDocument SamplingAdvantages and DisadvantagesAdvantages and Disadvantages

• It can be used to gather quantitative data, such as the average number of lines on an invoice, etc. (+)

• It can be used to find out about error rates in paper documents (+)

• If the system will change dramatically, existing documents may not reflect how it will be in future (-)


QuestionnairesQuestionnaires

• They consist of a series of written questions. The range of replies is usually limited (e.g. Yes or No).

• Some questions do not have a fixed number of responses, and must be left open-ended for the respondents to enter what they like.


QuestionnairesQuestionnairesAdvantages and DisadvantagesAdvantages and Disadvantages

• An economical way of gathering data from a large number of people. (++)

• If the questionnaire is well designed, then the results can be analysed easily. (possibly by computer) (+)

• Good questionnaires are difficult to construct. (-)• No automatic mechanism for follow up or probing more

deeply. (-)• Postal questionnaires suffer from low response rate. (-)


ElaborationElaboration• Elaboration is an analysis modelling action that is

composed of a number of modelling and refinement tasks.• There are two broad approaches to modelling (or two

modelling paradigms): structured/conventional and object-oriented.

• Both approaches are briefly discussed below.– Structured approach is reviewed in Week 3 (as it was

covered in CS2E23).– Object-oriented approach is covered in BS2011.


NegotiationNegotiation• Ideally, the previous steps should determine customer

requirements in sufficient detail to proceed to design. • In reality, the customer and the developer enter into a

process of negotiation, where the customer may be asked to balance functionality, performance and other product characteristics against cost and time to market.

• The objective of this negotiation is to develop a project plan that meets the needs of the customer while at the same time reflecting the real-world constraints (time, people, budget) that have been placed on the software team.

• The best negotiations strive for a ‘win-win’ result!


SpecificationSpecification

• The specification is the final work product produced by the requirements engineer (analyst). It serves as the foundation for subsequent software engineering activities (design, implementation, etc). It describes the function and performance of a computer-based system and the constraints that will govern its development.

• The specification usually combines text, graphical models, etc.


ValidationValidation• Requirements validation examines the specification to

ensure that all requirements have been stated unambiguously, that inconsistencies, omissions, and errors have been detected and corrected, and that the work product conforms to the standards established for the process, the project, and the product.

• The primary requirements validation mechanism is the formal technical review.


Systems Modelling ParadigmsSystems Modelling Paradigms

• Structured/’conventional’ paradigm– A system is viewed as a ‘collection’ of processes which

operate on data entities (‘stored’ in data stores/files/database).

– These processes correspond to various functional requirements, e.g. when we model a typical library system we are going to have such processes: Borrow Book, Return Book, Reserve Book etc. These processes operate on data entities Book, Loan, Reservation, etc.


Structured/’Conventional’ Structured/’Conventional’ View of a SystemView of a System


Systems Modelling Paradigms Systems Modelling Paradigms (cont.)(cont.)

• Object-oriented paradigm:– A system is viewed as a ‘collection’ of objects (class

instances). Each object/class encapsulates its attributes (i.e. data) and operations.

– Functional requirements (i.e. system functions) are ‘realised’ by collaborating objects. For example when we model a typical library system we are going to have such classes of objects: Book, Loan, Reader, etc. Function ‘Borrow Book’ will be ‘realised’ by corresponding operations of Book Object, Loan Object and possibly Reader Object. All these objects will collaborate to ‘realise’/process ‘Borrow Book’.


Object Oriented ‘View’ of a SystemObject Oriented ‘View’ of a System


What Do We Normally Model What Do We Normally Model Using Structured/Conventional Methods and Using Structured/Conventional Methods and

Techniques?Techniques?

• Functional requirements (to specify system’s functionality) e.g. using DFDs (processes, data flows, data stores, terminators/external entities)

• Data requirements (to specify system’s data) e.g. using ERDs (Logical Data Structures) (entities and relationships)

• Also we should specify which entities are manipulated/processed by which processes!!


How Do We Specify (How Do We Specify (in SSADMin SSADM) ) Which Entities Are Which Entities Are

Manipulated/Processed by Which Manipulated/Processed by Which Processes?Processes?

• Two modelling techniques are used to specify ‘connections’ between PROCESSES (in fact EVENTS that ‘trigger’ these processes) and ENTITIES.

• Effect Correspondence Diagram (ECD) shows which entities are affected by a given event (or a process ‘triggered’ by this event).

• Entity Life History (ELH) shows all of the events that can affect a given entity.


What Do We Normally Model What Do We Normally Model Using Object-Oriented Methods and Using Object-Oriented Methods and

Techniques?Techniques?• Functional requirements (to specify system’s functionality)

e.g. using Use cases and Use case diagrams (they will be discussed in BS2011!)

• Data requirements (to specify system’s data) e.g. using Class diagrams (these will be discussed in BS2011). Please note that classes encapsulate attributes/data and OPERATIONS! Therefore fully developed class diagrams show both!

• Also we should specify which use cases are ‘realised’ by which objects


How Do We Specify (How Do We Specify (in UMLin UML) ) Which Use Cases Are ‘Realised’ by Which Use Cases Are ‘Realised’ by

Which Objects?Which Objects?• The main UML techniques to specify ‘contribution’ of

objects to ‘realisation’ of use cases are Object Interaction Diagrams. In fact there are two types of interaction diagrams : sequence diagrams and collaboration diagrams (both types will be discussed in BS2011!)


SummarySummary

• Requirements engineering/analysis tasks• Systems modelling paradigms:

– Structured/Conventional– Object-Oriented

cc20o7n software engineering 1 cc2007n software engineering 1 introduction to requirements...

Documents

cc20o7n software engineering

cc2007n software engineering

usability requirements

elaboration basic requirements

objectoriented slide

problem elicitation

project stakeholders

work products