One to Three
description
Transcript of One to Three
![Page 1: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/1.jpg)
CHAPTER ONE
Introduction to Software Engineering
1
![Page 2: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/2.jpg)
Why Software Engineering?• Software development is hard! • Important to distinguish “easy” systems (one developer, one
user, experimental use only) from “hard” systems (multiple developers, multiple users, products)
• Experience with “easy” systems is misleading– One person techniques do not scale up
• Analogy with bridge building:– Over a stream = easy, one person job– Over River Severn … ? (the techniques do not scale)
• The problem is complexity• Many sources, but size is key:
– UNIX contains 4 million lines of code– Windows 2000 contains 108 lines of code
NB: Software engineering is about managing this complexity.2
![Page 3: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/3.jpg)
FAQs about software engineering
• What is – software?– software process?– software engineering?– software process model?
3
![Page 4: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/4.jpg)
What is software?• Computer programs and associated documentation
• Software products may be developed for a particular customer or may be developed for a general market
• Software products may be– Generic - developed to be sold to a range of different
customers– Bespoke (custom) - developed for a single customer
according to their specification
4
![Page 5: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/5.jpg)
What is software engineering?
Software engineering is an engineering discipline which is concerned with all aspects of software production
Software engineers should – adopt a systematic and organised approach to their
work – use appropriate tools and techniques depending on
• the problem to be solved, • the development constraints and • the resources available
5
![Page 6: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/6.jpg)
What is the difference between software engineering and computer science?
Computer Science Software Engineeringis concerned with
Computer science theories are currently insufficient to act as a complete underpinning for software engineering, BUT it is a foundation for practical aspects of software engineering
theory fundamentals
Algorithms, date structures, complexity theory, numerical methods
the practicalities of developing delivering useful software
SE deals with practical problems incomplex software products
6
![Page 7: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/7.jpg)
Software Engineering Body of Knowledge
Source: http://www.sei.cmu.edu/pub/documents/99.reports/pdf/99tr004.pdf7
![Page 8: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/8.jpg)
SE history
• SE introduced first in 1968 – conference about “software crisis” when the introduction of third generation computer hardware led more complex software systems then before
• Early approaches based on informal methodologies leading to– Delays in software delivery– Higher costs than initially estimated– Unreliable, difficult to maintain software
• Need for new methods and techniques to manage the production of complex software.
8
![Page 9: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/9.jpg)
Software myths
• Management myths– Standards and procedures for building software– Add more programmers if behind the schedule
• Customer myths– A general description of objectives enough to start coding– Requirements may change as the software is flexible
• Practitioner myths– Task accomplished when the program works– Quality assessment when the program is running– Working program the only project deliverable
99
![Page 10: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/10.jpg)
Software failures• Therac-25 (1985-1987): six people overexposed during
treatments for cancer• Taurus (1993): the planned automatic transaction settlement
system for London Stock Exchange cancelled after five years of development
• Ariane 5 (1996): roket exploded soon after its launch due error conversion (16 floating point into 16-bit integer)
• The Mars Climate Orbiter assumed to be lost by NASA officials (1999): different measurement systems (Imperial and metric)
• However, important Progresses– Ability to produce more complex software has increased– New technologies have led to new SE approaches– A better understanding of the activities involved in software
development– Effective methods to specify, design and implement software
have been developed– New notations and tools have been produced
1010
![Page 11: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/11.jpg)
What is a software process?• SP is a set of activities whose goal is the development or evolution of software• Fundamental activities in all software processes are:
– Specification - what the system should do and its development constraints– Development - production of the software system (design and implementation) – Validation - checking that the software is what the customer wants– Evolution - changing the software in response to changing demands
• What is a software process model?: SPM is a simplified representation of a software process, presented from a specific perspective– Examples of process perspectives:
• Workflow perspective: represents inputs, outputs and dependencies • Data-flow perspective: represents data transformation activities • Role/action perspective: represents the roles/activities of the
people involved in software process
– Generic process models• Waterfall• Evolutionary development• Formal transformation• Integration from reusable components 1111
![Page 12: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/12.jpg)
What are the costs of software engineering?
• Roughly 60% of costs are development costs, 40% are testing costs. For custom software, evolution costs often exceed development costs
• Costs vary depending on the type of system being developed and the requirements of system attributes such as performance and system reliability
• Distribution of costs depends on the development model that is used
1212
![Page 13: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/13.jpg)
What is CASE ? (Computer-Aided Software Engineering)
• Upper-CASE– Tools to support the early process
activities of requirements and design• Lower-CASE
– Tools to support later activities such as programming, debugging and testing
Software systems which are intended to provide automated support for software process activities, such as requirements analysis, system modelling, debugging and testing
1313
![Page 14: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/14.jpg)
What are the attributes of good software?
• Maintainability– Software must evolve to meet changing needs
• reliability– Software must be trustworthy
• Efficiency– Software should not make wasteful use of system resources
• Usability– Software must be usable by the users for which it was
designed
The software should deliver the required functionality and performance to the user and should be
maintainable, reliable and usable
1414
![Page 15: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/15.jpg)
What are the key challenges facing software engineering?
Software engineering in the 21st century faces three key challenges:
• Legacy systems– Old, valuable systems must be maintained and updated
• Heterogeneity– Systems are distributed and include
a mix of hardware and software
• Delivery– There is increasing pressure for faster delivery of software
1515
![Page 16: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/16.jpg)
Object Oriented Concepts• Object-oriented
– Means to organize the software as a collection of discrete objects that incorporate both data structure and behaviour
• Object concepts• We continue to explore the question “what are good
systems like?” by describing the object oriented paradigm.
• We shall answer these questions:– What is an object?– How do objects communicate?– How is an object’s interface defined?– What have objects to do with components?
• Finally we consider inheritance, polymorphism and dynamic binding.
1616
![Page 17: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/17.jpg)
What is an object?• Conceptually, an object is a thing you can interact with:
– you can send it various messages and – it will react
• How it behaves depends on the current internal state of the object, which may change– For example: as part of the object’s reaction to receiving a
message.• It matters which object you interact with, an object has an
identity which distinguishes it from all other objects.
An object is a thing which has – behaviour, – state and – identity [Grady Booch, 1991]
1717
![Page 18: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/18.jpg)
State• The state of the object is all the data which it currently encapsulates• An object normally has a number of named attributes (or instance
variables or data members) each of which has a value• Some attributes can be mutable
– An attribute ADDRESS • other attributes may be constant (immutable)
– Date of birth– Identifying number
Behaviour• The way an object acts and reacts, in terms of its state
changes as message passing.• An object understands certain messages,
• it can receive the message and act on them.• The set of messages that the object understands, like the set
of attributes it has, is normally fixed. 1818
![Page 19: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/19.jpg)
Identity - is a little more slippery
• The idea is that objects are not defined just by the current values of their attributes
• An object has continues existence – For example the values of the object’s attributes
could change, perhaps in response to a message, but it would still be the same object.
• An object is normally referred to by a name, but the name of the object is not the same thing as the object, because the same object may have several different names
1919
![Page 20: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/20.jpg)
Example • Consider an object which we’ll call myClock, which
understands the messages:– reportTime– resetTimeTo(07:43), resetTimeTo(12:30) or indeed more
generally resetTimeTo(newTime) • How does it implements this functionality?• The outside world doesn’t need to know – the information
should be hidden !!! – but perhaps it has an attribute time – Or perhaps it passes these messages on to some other
object, which it knows about, and has the other object deal with messages
2020
![Page 21: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/21.jpg)
Object: classification• objects with the same data structure (attributes) and behaviour
(operations) are grouped into a class• each class defines a possibly infinite set of objects• Each object is an instance of a class• Each object knows its class• Each instance has its own value for each attribute (state) but
shares the attribute names and operations with other instances of the class– also “static” i.e. class variables
• class encapsulates data and behaviour, hiding implementation details of an object
21
![Page 22: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/22.jpg)
Deviation: why have classes????
• Why not just have objects, which have state, behaviour and identity as we require?
• Classes in object oriented languages serve two purposes:– Convenient way of describing a collection (a class) of objects
which have the same properties– In most modern OO languages, classes are used in the same way
that types are used in many other languages• To specify what values are acceptable
Classes and types• Often people think of classes and types as being the same thing
(indeed it is convenient and not often misleading, to do so). However, it’s wrong!
• Remember that a class defines not only what messages an object understand!
• It also defines what the object does in response to the messages. 2222
![Page 23: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/23.jpg)
Object: inheritance• the sharing of attributes and operations among classes based upon
a hierarchical relationship• class can be defined broadly and then refined into successively
finer subclasses• each subclass incorporates or inherit all the properties of its super
class and its own unique properties• Subclass Superclass
– A subclass is an extended, specialized version of its superclass. – It includes the operations and attributes of the superclass, and
possibly some more• Inheritance – warning
– (!) An object class is coupled to its super-classes. Changes made to the attributes or operations in a super-class propagate to all sub-classes 2323
![Page 24: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/24.jpg)
Object: Polymorphism
• it means that the same operation may behave differently on objects of different underlying class while being referenced as a superclass
• OOPL automatically selects the correct method to implement an operation based on the name of the operation (method signature) and the object’s class being implemented
• Polymorphism – exampleVehicle v = null;v = new Car();v.startEngine();v = new Boat();v.startEngine();
2424
![Page 25: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/25.jpg)
CHAPTER TWO
The Unified Process
25
![Page 26: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/26.jpg)
Grady Booch speaks
“People are more important than any process.
Good people with a good process will outperform good people with no process any time.”
26
![Page 27: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/27.jpg)
Overview• Unified Process is component based
– system is built using software components interconnected using well defined interfaces
• Unified Process uses Unified Modelling Language (UML)
• Unified Process is distinguished by being• use-case driven• architecture-centric• iterative and incremental
• Based around the 4Ps - People, Project, Product, Process
27
![Page 28: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/28.jpg)
Cont...
• Provides disciplined approach to assigning tasks and responsibilities
• Guide for how to use Unified Modelling Language (UML) effectively
• Activities create and maintain (UML) models• Is a configurable process
28
![Page 29: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/29.jpg)
Characteristics of Modern Systems
• Volatile business environment subject to constant change - BPR; rapid IS development needed
• Wide range of more complex system types CAD/CAM, GIS, Office Automation, CASE tools
• Increased use of complex data types - text documents, video, sound, graphics, spatial data
• Sophisticated user interfaces (GUIs)• Client-Server environments / distributed systems• Tendency for larger systems with complex and varied
interrelationships among software components
29
![Page 30: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/30.jpg)
Effective Deployment of 6 best practices
• Develop software iteratively• Manage requirements• Use component-based architectures• Visually model software• Verify software quality• Control changes to software
30
![Page 31: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/31.jpg)
Unified Process : Use Case Driven• Use Case
“A description of a set of sequence of actions, including variants, that a system performs which yields an observable result of
value to a particular actor.”(Jacobson et.al. 1999)
– i.e. A piece of functionality that gives a user a result of value• Development process follows a flow
– proceeds through a series of workflows derived from the use cases
– use cases are specified, designed and are the source for test cases
– they drive system architecture which in turn influences use case selection
– both mature as the development lifecycle continues 31
![Page 32: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/32.jpg)
Unified Process : Architecture-Centric• Software architecture shows different views of the
system being built and embodies the static & dynamic aspects of the system (design framework)
• Also influenced by the computer architecture, operating system, DBMS, network protocols etc.
• Related as function (use case) and form (architecture) • The form must allow the system to evolve from initial
development through future requirements (i.e. the design needs to be flexible)
• Key use cases influence the design of the architecture which may in turn influence development of other use cases
32
![Page 33: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/33.jpg)
Unified Process : Iterative and Incremental• Systems development is frequently a large undertaking - may
be divided into several “mini-projects” each of which is an iteration resulting in incremental development of the system
• Iterations must be selected & developed in a planned way i.e. in a logical order - early iterations must offer utility to the users
• iteration based on a group of use cases extending the usability of the system developed so far
• iterations deal with the most important risks first• not all iterations are additive - some replace earlier
“superficial” developments with a more sophisticated and detailed one.
• Concepts of use case driven, architecture centric and iterative & incremental are of equal importance
33
![Page 34: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/34.jpg)
An iterative and incremental process
Initial Planning
Analysis & Design
Evaluate
ImplementationManagementEnvironment
Planning
Requirements
DeploymentTest
Each iterationresults in executablerelease
34
![Page 35: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/35.jpg)
Benefits of an iterative approach
• Risks are mitigated earlier• Change is more manageable• Higher level of reuse• Project team can learn along the way• Better overall quality
35
![Page 36: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/36.jpg)
Life Cycle of the Unified Process• Unified Process repeats over a series of cycles each
concluding with a product release to the users• Each cycle has 4 phases (each with a number of
iterations)• Inception, Elaboration, Construction & Transition
• Delivered products will be described by related models each with “trace” dependencies which chain backwards and forwards
• Use Case Model; Analysis Model; Design Model• Deployment Model; Implementation Model;
Test Model36
![Page 37: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/37.jpg)
Cont…
• The Unified Software Process has four phases:– Inception - Define the scope of project– Elaboration - Plan project, specify features,
baseline architecture– Construction - Build the product– Transition - Transition the product into end
user community
37
![Page 38: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/38.jpg)
Core Workflows & Phases
38
![Page 39: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/39.jpg)
The 4Ps in Software Development
Process
Product
People Project ToolsParticipants
Template
Automation
Result
39
![Page 40: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/40.jpg)
People• People are an integral part of the lifecycle of a software
product, therefore, the process that guides the development must be people orientated
• Actual development process affects people• project feasibility / risk management / team
structure• project schedule / project understandability / sense
of achievement• In modern large and complex systems developers will be
part of a team and will be playing varying and changing roles within it
• Allocation of tasks should maximise project experience40
![Page 41: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/41.jpg)
Project• The first project in the lifecycle (“green-field”
project) develops & releases the initial system; successive cycles extend the life of the system over many releases
• The project team will have to be concerned with:– A sequence of change– A series of iterations– An organisational pattern
41
![Page 42: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/42.jpg)
Product• The product is the developed system and comprises:
– Software system (executables, machines, procedures)– Artifacts developed (UML models, prototypes etc.)– A collection of models and relationships between
them• Use Case Model; Analysis Model; Design
Model• Deployment Model; Implementation Model; Test
Model• In the Unified Process the set of models illuminate the
system from the perspective of all people involved in the project (users, developers, project managers) 42
![Page 43: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/43.jpg)
Process• The Unified Software Development Process is a
definition of a complete set of activities to transform users’ requirements through a consistent set of artefacts into a software product
• Unified Process is a template and each project is a process instance of the template (i.e. the template is the definition of the set of activities not the execution of them)
• A process is described in terms of workflows where a workflow is a set of activities with identified artifacts that will be created by those activities
43
![Page 44: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/44.jpg)
Static Structure of ProcessesA process describes ‘who, ‘what’, ‘when’ ‘how’
Workers (who) Activities (how)
Artifacts (what)
Workflow (when) - sequence of activities
Designer Use Case Analysis Use Case Design
responsible for
Use caserealisation
44
![Page 45: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/45.jpg)
Requirements engineeringRequirements engineering is the process of establishing: •the services that the customer requires from a system •the constraints under which it operates and is developed
Requirements The descriptions of the system services and constraints
that are generated during the requirements engineering process
45
![Page 46: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/46.jpg)
What is a requirement?
• It may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification
• This is inevitable as requirements may serve a dual function– May be the basis for a bid for a contract - therefore must be
open to interpretation– May be the basis for the contract itself - therefore must be
defined in detail– Both these statements may be called requirements
46
![Page 47: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/47.jpg)
Types of requirement• User requirements
– Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers
• System requirements– A structured document setting out detailed
descriptions of the system services. Written as a contract between client and contractor
• Software specification– A detailed software description which can serve as a
basis for a design or implementation. Written for developers 47
![Page 48: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/48.jpg)
Requirements readersClient managersSystem end-usersClient engineersContractor managersSystem architects
System end-usersClient engineersSystem architectsSoftware developers
Client engineers (perhaps)System architectsSoftware developers
User requirements
System requirements
Software designspecification
48
![Page 49: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/49.jpg)
Functional and non-functional requirements
• Functional requirements– Statements of services the system should provide,
how the system should react to particular inputs and how the system should behave in particular situations.
• Non-functional requirements– constraints on the services or functions offered by the
system such as timing constraints, constraints on the development process, standards, etc.
• Domain requirements– Requirements that come from the application domain
of the system and that reflect characteristics of that domain
49
![Page 50: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/50.jpg)
Functional RequirementsDescribe functionality or system services
• Depend on the type of software, expected users and the type of system where the software is used
• Functional user requirements may be high-level statements of what the system should do BUT functional system requirements should describe the system services in detail
50
![Page 51: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/51.jpg)
Examples of functional requirements
• The user shall be able to search either all of the initial set of databases or select a subset from it.
• The system shall provide appropriate viewers for the user to read documents in the document store.
• Every order shall be allocated a unique identifier (ORDER_ID) which the user shall be able to copy to the account’s permanent storage area.
51
![Page 52: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/52.jpg)
Requirements imprecision
• Problems arise when requirements are not precisely stated
• Ambiguous requirements may be interpreted in different ways by developers and users
• Consider the term ‘appropriate viewers’– User intention - special purpose viewer for each
different document type– Developer interpretation - Provide a text viewer that
shows the contents of the document
52
![Page 53: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/53.jpg)
Requirements completeness and consistency
• In principle requirements should be both complete and consistentComplete– They should include descriptions of all facilities
requiredConsistent– There should be no conflicts or contradictions in the
descriptions of the system facilities• In practice, it is very difficult or impossible to
produce a complete and consistent requirements document
53
![Page 54: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/54.jpg)
Non-functional requirementsDefine system properties and constraints e.g. reliability, response time and storage requirements. Constraints are I/O device capability, system representations, etc.
• Process requirements may also be specified mandating a particular CASE system, programming language or development method
• Non-functional requirements may be more critical than functional requirements. If these are not met, the system is useless
54
![Page 55: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/55.jpg)
Non-functional Requirements classifications
• Product requirements– Requirements which specify that the delivered product must
behave in a particular way e.g. execution speed, reliability, etc.
• Organisational requirements– Requirements which are a consequence of organisational
policies and procedures e.g. process standards used, implementation requirements, etc.
• External requirements– Requirements which arise from factors which are external to
the system and its development process e.g. interoperability requirements, legislative requirements, etc.
55
![Page 56: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/56.jpg)
Examples
• A system goal– The system should be easy to use by experienced
controllers and should be organised in such a way that user errors are minimised.
• A verifiable non-functional requirement– Experienced controllers shall be able to use all the system
functions after a total of two hours training. After this training, the average number of errors made by experienced users shall not exceed two per day.
56
![Page 57: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/57.jpg)
Requirements measuresProperty MeasureSpeed Processed transactions/second
User/Event response timeScreen refresh time
Size K BytesNumber of RAM chips
Ease of use Training timeNumber of help frames
Reliability Mean time to failureProbability of unavailabilityRate of failure occurrenceAvailability
Robustness Time to restart after failurePercentage of events causing failureProbability of data corruption on failure
Portability Percentage of target dependent statementsNumber of target systems
57
![Page 58: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/58.jpg)
Domain requirements
• Derived from the application domain and describe system characteristics and features that reflect the domain
• May be new functional requirements, constraints on existing requirements or define specific computations
• If domain requirements are not satisfied, the system may be unworkable
58
![Page 59: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/59.jpg)
Domain requirements problems
• Understandability– Requirements are expressed in the language of the
application domain– This is often not understood by software engineers
developing the system
• Implicitness.... /indirectness– Domain specialists understand the area so well that they
do not think of making the domain requirements explicit
59
![Page 60: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/60.jpg)
User requirements
• Should describe functional and non-functional requirements so that they are understandable by system users who don’t have detailed technical knowledge
• User requirements are defined using natural language, tables and diagrams
60
![Page 61: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/61.jpg)
Problems with natural language
• Lack of clarity – Precision is difficult without making the document difficult
to read
• Requirements confusion– Functional and non-functional requirements tend to be
mixed-up
• Requirements amalgamation/ mix– Several different requirements may be expressed together
61
![Page 62: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/62.jpg)
System requirements
– More detailed specifications of user requirements
• Serve as a basis for designing the system
• May be used as part of the system contract
• System requirements may be expressed using system models (will be discussed in Chapter 3 & 4)
62
![Page 63: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/63.jpg)
The requirements analysis document
• The requirements document is the official statement of what is required of the system developers
• Should include both a definition and a specification of requirements
• It is NOT a design document. As far as possible, it should set of WHAT the system should do rather than HOW it should do it
63
![Page 64: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/64.jpg)
CHAPTER THREE
USE Case Design
64
![Page 65: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/65.jpg)
Why Use Cases?
• Use Case– A set of scenarios related by a common actor and a goal– A description of sequences of actions performed by a given
system to produce a result for an actor• Use cases specify the expected behavior [what], and not
the exact method of making it happen [how]• Use cases are created based on identified functional
requirements but are not mapped one-to-one to requirements
• Use cases once specified can be denoted using a clear and precise visual modeling language such as UML
65
![Page 66: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/66.jpg)
Terms and Concepts• Actors
– Represent roles that humans, hardware devices, or external systems play while interacting with a given system
– They are not part of the system and are situated outside of the system boundary
– Actors may be both at input and output ends of a use case– Primary or Secondary– Notation:
66
![Page 67: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/67.jpg)
Cont…• Use case
– A set of interactions between a system and an external person or system that achieves a goal.
– defines a goal-oriented set of interactions between external actors and the system under consideration
– is initiated by a user with a particular goal in mind, and completes successfully when that goal is satisfied
– capture who (actor) does what (interaction) with the system, for what purpose (goal), without dealing with system internals.
– use case steps are written in an easy-to-understand structured narrative using the vocabulary of the domain
– Notation:
Use case Name67
![Page 68: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/68.jpg)
Cont…• Scenarios
– instance of a use case, and represents a single path through the use case
– Specify behavior of use case by description, not modeling• Examples include informal structured text, formal
structured text with conditions, and pseudo-code– Typically specifies:
• How and when the use case starts and ends• Interaction with the actors and the exchange of objects• Flow of events: main / typical (success and exceptional
(failure) flows
68
![Page 69: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/69.jpg)
Cont…• Scenarios Example:
– In a human resources system, for the “Hire Employee” use case, the following scenarios may apply:• Typical success scenario: Hire a person from
outside of the company, for example, from another company
• Alternative success scenario: Hire a person from within the same company, for instance, from another division
• Exceptional failure scenario: No qualified person could be hired
69
![Page 70: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/70.jpg)
Cont…
• Entry and Exit Conditions– Entry conditions describe the environment under
which the use case is invoked– Exit conditions reflect the impact of the use case on
the environment through its execution• Quality Requirements
– Describe quality attributes in terms of a specific functionality
– For example, requires system response in < 30 seconds
70
![Page 71: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/71.jpg)
Cont….• Relationships
– Organize use cases by grouping them in packages– Generalization: The child use case exhibits a more
specific variation in behavior than as specified for its parent
– Include: Common behavior of more than one use case is referenced as a separate instance to avoid repetition
– Extend: Implicit integration of the behavior of another use case by declaring the extension points / events in the base
71
![Page 72: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/72.jpg)
Identifying Actors, Use Cases, and Scenarios
• Identifying Actors:– Define system boundary to identify actors correctly– Identify users and systems that depend on the
system’s primary and secondary functionalities– Identify hardware and software platforms with which
the system interacts– Select entities that play distinctly different roles in
the system– Identify as actors external entities with common
goals and direct interaction with the system– Denote actors as nouns
72
![Page 73: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/73.jpg)
Cont…• Identifying Use Cases:
– Business / Domain Use Cases:• Interactions between users and the business (or domain)
– System Use Cases:• Interactions between users and the system• One business use cases contains a set of system use cases
– To name the use cases, give it a verb name to show the action that must be performed
• Describe a transaction completely• No description of user interface whatsoever
– Capture use cases during requirements elaboration
73
![Page 74: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/74.jpg)
Cont…
• Identifying Scenarios– Extract the functionality that is available to each actor– Establish specific instances and not general
descriptions– Denote situations in the current and future systems– Identify:
• Tasks to be performed by the user and the system• Flow of information to the user and to the system• Events that are conveyed to the user and to the system• For the events flow, name steps in active voice
74
![Page 75: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/75.jpg)
UML Use Cases Example
75
![Page 76: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/76.jpg)
Courseware System Description• Informal Description:For this case study, the task is of constructing the design elements for a
system that can be used to manage courses and classes for an organization that specializes in providing raining. The name of the system is Courseware System. The organization offers courses in a variety of areas such as learning management techniques and understanding different software languages and technologies. Each course is made up of a set of topics. Tutors in the organization are assigned courses to teach according to the area that they specialize in and their availability. The organization publishes and maintains a calendar of the different courses and the assigns tutors every year. There is a group of course administrators in the organization who manage the courses including course content, assigning courses to tutors, and defining the course schedule. The training organization aims to use the Courseware System to get a better control and visibility to the course management and to also streamline the process of generating and managing schedules for different courses
76
![Page 77: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/77.jpg)
Courseware Overview
• The following terms and entities are specific to the system:– Courses and Topics that make up courses– Tutors that teach courses– Course Administrators who manage the assignment
of courses to tutors– Calendars and Course Schedules that are generated
as a result of the work performed by the course administrators
– Students who refer to Calendars and Course Schedules to decide which courses they wish to take up for study
77
![Page 78: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/78.jpg)
Courseware Actors and Use Cases
• Actors: Tutor, Student, Course Administrator (main actor)
• Use Cases (primary business: secondary user)– Manage courses: View courses, Manage topics for a
course, and Manage course information– Manage tutors: View course calendar, View tutors,
Manage tutor information, and Assign courses to tutors
78
![Page 79: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/79.jpg)
79
![Page 80: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/80.jpg)
80
![Page 81: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/81.jpg)
Courseware Scenarios Example /1• Use Case: Manage Course Information (UC_ID1)
– Participating Actors: Course Administrator– Entry Conditions: Course Administrator is logged into
CourseWare– Exit Conditions: Course Administrator has received
an acknowledgement from the system that the selected transaction is complete, or if not complete, a message explaining the failure
– Quality Requirements: (Performance) Course Administrator receives a response from the system in less than 3 seconds
– Related Requirements: Create, Modify, and Delete Course
81
![Page 82: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/82.jpg)
Courseware Scenarios Example /2
• Use Case: Manage Course Information (UC_ID1)– Typical flow of events:
1. Course Administrator selects Create New Course a) System invokes Create New Course use case
2. Course Administrator selects Modify Existing Coursea) System invokes Modify Existing Course use case
82
![Page 83: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/83.jpg)
Courseware Scenarios Example /3• Use Case: Create New Course (UC_ID2)
– Participating Actors: Course Administrator– Extends: Manage Course Information (UC_ID1)– Entry Conditions: Course Administrator has selected
Create New Course option– Exit Conditions: Course Administrator has received an– acknowledgement from the system that a course has
been created, or if not, a message explaining the failure– Quality Requirements: (Performance) Course
Administrator receives a response from the system in less than 3 seconds
– Related Requirements: Create Course83
![Page 84: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/84.jpg)
Courseware Scenarios Example /4• Use Case: Manage Course Information (UC_ID2)
– Typical flow of events:1.Course Administrator enters New Course Information
a) System invokes Validate Course Information use caseb) For a valid response, system creates a new course
entry and sends an acknowledgment back to the actor
– Exceptions:1. Course Administrator enters New Course Information
a) Invalid response received, so system reports failure with a message indicating invalid course information
84
![Page 85: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/85.jpg)
Courseware Scenarios Example /5• Use Case: Modify Existing Course (UC_ID3)
– Participating Actors: Course Administrator– Extends: Manage Course Information (UC_ID1)– Entry Conditions: Course Administrator has selected
Modify Existing Course option– Exit Conditions: Course Administrator has received an
acknowledgement from the system that a course has been modified, or if not, a message explaining the failure
– Quality Requirements: (Performance) Course Administrator receives a response from the system in less than 3 seconds
– Related Requirements: Modify and Delete Course85
![Page 86: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/86.jpg)
Courseware Scenarios Example /6• Use Case: Modify Existing Course (UC_ID3)
– Typical flow of events:1. Course Administrator selects Find Existing Course
option a) System searches for a selected course and
returns existing course information2. Course Administrator enters new course
information a) System invokes Validate Course Information
use caseb) For a valid response, system updates the
existing course entry and sends an acknowledgment back to the actor
86
![Page 87: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/87.jpg)
Courseware Scenarios Example /7• Use Case: Modify Existing Course (UC_ID3)
– Alternatives:1. Course Administrator selects Delete Existing Course
optiona) System invokes Delete Existing Course use case
– Exceptions:1. Course Administrator selects Find Existing Course option
a) System searches for a selected course and returns failure stating that the course could not be found
2. Course Administrator enters New Course Informationa) Invalid response received, so system reports failure
with a message indicating invalid course information
87
![Page 88: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/88.jpg)
Courseware Scenarios Example /8• Use Case: Delete Existing Course (UC_ID4)
– Participating Actors: Course Administrator– Extends: Modify Existing Course (UC_ID3)– Entry Conditions: Course Administrator has selected
Delete Existing Course option– Exit Conditions: Course Administrator has received an
acknowledgement from the system that a course has been deleted, or if not, a message explaining the failure
– Quality Requirements: (Performance) Course Administrator receives a response from the system in less than 3 seconds
– Related Requirements: Delete Course 88
![Page 89: One to Three](https://reader036.fdocuments.in/reader036/viewer/2022081513/577cc75f1a28aba711a0bc20/html5/thumbnails/89.jpg)
Courseware Scenarios Example /9• Use Case: Delete Existing Course (UC_ID4)
– Typical flow of events: a) System deletes a selected course and sends an
acknowledgment back to the user– Exceptions:
a) System cannot delete a selected course so it returns failure stating that the course could not be deleted
89