Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
04/08/2011
Syllabus
Introduction Software Process Software Development Life Cycle Software Qualities Problems with Software Production Brooks No Silver Bullet Software Life-Cycle Models Build-and-fix Waterfall Rapid Prototyping
04/08/2011
Mrs. Sankita Patel Software Engineering @ B.Tech.IV
Syllabus(contd)
Incremental Spiral Comparison of all models ISO 9000-CMM levels-Comparison Software Requirements and Analysis Techniques Feasibility Analysis Requirement Elicitation Validation Rapid Prototyping
04/08/2011
Mrs. Sankita Patel Software Engineering @ B.Tech.IV
Syllabus(contd)
OO Paradigms vs. Structured Paradigm OO Analysis CASE tools Software Specification Specification Document Specification Qualities, Uses Specification classification-Operational Behavioral-DFD UML Petri nets Descriptive Specifications
04/08/2011
Mrs. Sankita Patel Software Engineering @ B.Tech.IV
Syllabus(contd)
ER Diagrams, Logic, Algebraic Specs Comparison of various techniques and CASE tools Introduction to Formal Approach Formal Specifications Software Verification & Validation Clean-room Engineering Formal Approaches Model Checking-SPIN tool
04/08/2011
Syllabus(contd)
Case tools, ISO and Capability Maturity Model CASE tools Stepwise Refinement Cost-Benefit Analysis Scope of CASE Versions control ISO and CMM Software Testing Principles Non-execution & Execution based testing Automated static Analysis
04/08/2011
Mrs. Sankita Patel Software Engineering @ B.Tech.IV
Syllabus(contd)
Test-case selection Black-Box and Glass-Box Testing Testing Objects Testing vs. Correctness Proof Maintenance Phase
04/08/2011
04/08/2011
Software characteristics
The holistic view Software is a set of items or objects that form a configuration that includes programs, data, documents. Software is often, large and complex built by teams exist in many versions last many years undergo changes
04/08/2011
Mrs. Sankita Patel Software Engineering @ B.Tech.IV
10
Definitions of SE
Definitions of SE : is a field of computer science dealing with software systems large and complex, often undergo changes is multi-person construction, multi-version software (Parnas 1978) is an application of a systematic, disciplined, quantifiable approach to the development, operation, maintenance of software (IEEE 1990) SE is a discipline whose aim is the production of faultfree software, delivered on time & within budget, that satisfies the users needs and that is easy to modify
04/08/2011
Mrs. Sankita Patel Software Engineering @ B.Tech.IV
11
Historical origins of SE
What does Software Engineering attempt to do ? Student coding productivity vis--vis industry coding. The field of software engineering was born in 1968 in response to chronic failures of large software projects to meet schedule & budget constraints Recognition of "the software crisis Define clearly the problem you are trying to solve and then use and develop standard tools and techniques for solving it. Use paradigms, practices & philosophies of established Engg. disciplines to solve software crisis.
4-Aug-11
Mrs. Sankita Patel Software Engineering @ B.Tech.IV
12
04/08/2011
13
waterfall model
Code and module testing Integration and sy stem testing Deliv ery and maintenance
04/08/2011
Mrs. Sankita Patel Software Engineering @ B.Tech.IV
14
4-Aug-11
15
16
Software Requirements
04/08/2011
17
18
Outline
Functional and non-functional requirements User requirements System requirements Interface specification The software requirements document
04/08/2011
19
Requirements engineering
Requirements: The description of the services provided by the system and its operational constraints Requirement Engineering(RE): The process of finding out, analysing, documenting and checking these services and constraints
04/08/2011
20
What is a requirement?
Requirement: Can be a high-level abstract statement of a service Can be a detailed, formal definition of a system function 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.
04/08/2011
21
Types of requirement
User requirements High level abstract requirement Statements in natural language plus diagrams of the services the system provides and its operational constraints. System requirements Detailed description of what the system should do A structured document setting out detailed descriptions of the systems functions, services and operational constraints. Defines what should be implemented so may be part of a contract between client and contractor.
04/08/2011
Mrs. Sankita Patel Software Engineering @ B.Tech.IV
22
Sy stem requir ements specification 1.1 The user should be pr ovided with facilities to define the ty pe of 1.2 external files . 1.2 Each e xternal file ty pe ma y have an associa ted tool w hich ma y be 1.2 applied to the file . 1.3 Each e xternal file ty pe ma y be repr esented as a specific icon on 1.2 the user s displa y . 1.4 Facilities should be pr o vided for the icon r epresenting an 1.2 external file ty pe to be defined b y the user . 1.5 When a user selects an icon r epr esenting an e xternal file, the 1.2 effect of that selection is to apply the tool associated with the ty pe of 1.2 the external file to the file represented by the selected icon.
04/08/2011
23
Requirements readers
Client managers System end-users Client eng ineers Contractor managers System architects System end-users Client eng ineers System architects Software developers
User requirements
System requirements
04/08/2011
24
Non-functional requirements
constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc. Generally applied to the system as a whole.
Domain requirements
Requirements that come from the application domain of the system and that reflect characteristics of that domain.
04/08/2011
25
Functional requirements
Describe 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.
04/08/2011
26
04/08/2011
27
Every order shall be allocated a unique identifier (ORDER_ID) which the user shall be able to copy to the accounts permanent storage area.
04/08/2011
28
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.
04/08/2011
29
30
Non-functional requirements
Define 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. E.g. What if aircraft system doesnt meet reliability requirement??? E.g. What if a real-time control system fails to meet its performance requirement??
04/08/2011
Mrs. Sankita Patel Software Engineering @ B.Tech.IV
31
Non-functional 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.
04/08/2011
32
Organisational requirement
The system development process and deliverable documents shall conform to the process and deliverables defined in XYZCo-SP-STAN-95.
External requirement
The system shall not disclose any personal information about customers apart from their name and reference number to the operators of the system.
04/08/2011
33
04/08/2011
34
Goals are helpful to developers as they convey the intentions of the system users.
04/08/2011
35
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.
04/08/2011
36
Requirements measures
Property Speed Measure Processed transactions/second User/Event response time Screen refresh time M Bytes Number of ROM chips Training time Number of help frames Mean time to failure Probability of unavailability Rate of failure occurrence Availability Time to restart after failure Percentage of events causing failure Probability of data corruption on failure Percentage of target dependent statements Number of target systems
Robustness
Portability
04/08/2011
37
Requirements interaction
Conflicts between different non-functional requirements are common in complex systems. Spacecraft system To minimise weight, the number of separate chips in the system should be minimised. To minimise power consumption, lower power chips should be used. However, using low power chips may mean that more chips have to be used. Which is the most critical requirement?
04/08/2011
38
Domain requirements
Derived from the application domain and describe system characteristics and features that reflect the domain. Domain requirements be new functional requirements, constraints on existing requirements or define specific computations. If domain requirements are not satisfied, the system may be unusable.
04/08/2011
39
04/08/2011
40
04/08/2011
41
User requirements
Should describe functional and non-functional requirements in such a way that they are understandable by system users Should only specify external behaviour of system and avoid details as far as possible Avoid using software jargon, structured notations or formal notations Should be defined using natural language, tables and diagrams as these can be understood by all users.
04/08/2011
42
04/08/2011
43
LIBSYS requirement
LIBSYS shall provide a financial accounting system that maintains records of all payments made by users of the system. System managers may configure this system so that regular users may receive discounted rates.
04/08/2011
44
04/08/2011
45
System requirements
More detailed specifications of system functions, services and constraints than user requirements. They are intended to be a basis for designing the system. They may be incorporated into the system contract. System requirements may be defined or illustrated using system models
04/08/2011
46
04/08/2011
47
04/08/2011
48
Alternatives to NL specification
Notation Structured natural language Design description language s Graphical notations Description This approach depends on defining standard forms or templates to express the requirements specification. This approach uses a language like a programming langu age but with more ab stract features to specify the requirements by defining an operational model of the system. This approach is not now widely used although it can be useful for interface specifications. A graphical languag e, supplemented by text annotations is used to define the functional requirements for the system. An early example of such a graphical language was SADT. Now, use-case descriptions and sequence d iagrams are commonly used . These are notations based on mathematical concep ts such as finite-state machines or sets. These unambiguous specifications reduce the argu ments between customer and contractor about system functionality. However, most customers dont understand formal specifications and are reluctant to accept it as a system contract.
Mathematical specifications
04/08/2011
49
04/08/2011
50
51
Interface specification
Procedural interfaces Existing programs or sub-systems offer a range of services Application Programming Interfaces (APIs) Data Structures To be passed from one sub-system to another Can be best specified by graphical data models Representation of data Data that have been established for an existing sub-systems Most common in embedded systems
04/08/2011
52
04/08/2011
53
04/08/2011
54
04/08/2011
55
04/08/2011
56
57
Outline
Feasibility studies Requirements elicitation and analysis Requirements validation Requirements management Rapid prototyping OO Paradigms vs. Structured Paradigm OO Analysis CASE tools
04/08/2011
58
04/08/2011
59
04/08/2011
60
Requirements engineering
Sy stem requirements specification and modeling User requirements specification Business requirements specification Sy stem requirements elicitation User requirements elicitation Feasibility study Prototy ping Requirements elicitation Reviews Requirements validation Syst em requirements document
Requirements specification
Feasibility studies
A feasibility study decides whether or not the proposed system is worthwhile. Input to the feasibility study: A set of preliminary business requirements An outline description of the system How the system is intended to support business processes Output of feasibility study: A report that recommends whether or not it is worth carrying on with the requirements engineering and system development process
04/08/2011
Mrs. Sankita Patel Software Engineering @ B.Tech.IV
62
Feasibility studies
A short focused study that checks If the system contributes to organisational objectives; If the system can be engineered using current technology and within budget; If the system can be integrated with other systems that are used.
04/08/2011
63
04/08/2011
64
04/08/2011
65
04/08/2011
66
Process activities
Requirements discovery
Interacting with stakeholders to discover their requirements. Domain requirements are also discovered at this stage.
Requirements documentation
Requirements are documented and input into the next round of the spiral.
04/08/2011
67
Requirements discovery
The process of gathering information about the proposed and existing systems and distilling the user and system requirements from this information. Sources of information include documentation, system stakeholders and the specifications of similar systems.
04/08/2011
68
ATM stakeholders
Bank customers Representatives of other banks Bank managers Counter staff Database administrators Security managers Marketing department Hardware and software maintenance engineers Banking regulators
04/08/2011
69
Viewpoints
View point oriented architecture: A key strength is that it recognises multiple perspectives and provides a framework for discovering conflicts Stakeholders may be classified under different viewpoints. This multi-perspective analysis is important as there is no single correct way to analyse system requirements.
04/08/2011
70
Types of viewpoint
Interactor viewpoints
People or other systems that interact directly with the system. In an ATM, the customers and the account database are interactor VPs.
Indirect viewpoints
Stakeholders who do not use the system themselves but who influence the requirements. In an ATM, management and security staff are indirect viewpoints.
Domain viewpoints
Domain characteristics and constraints that influence the requirements. In an ATM, an example would be standards for inter-bank communications.
04/08/2011
71
Viewpoint identification
Identify viewpoints using Providers and receivers of system services; Systems that interact directly with the system being specified; Regulations and standards; Sources of business and non-functional requirements. Engineers who have to develop and maintain the system; Marketing and other business viewpoints.
04/08/2011
72
Indirect
Interactor
Domain
Library manager
Finance
Ar ticle providers
Users
Library staff
UI standards
Classification sy stem
Students
Staff
External
Sy stem managers
Cataloguers
04/08/2011
73
Interviewing
In formal or informal interviewing, the RE team puts questions to stakeholders about the system that they use and the system to be developed. There are two types of interview Closed interviews where a pre-defined set of questions are answered. Open interviews where there is no pre-defined agenda and a range of issues are explored with stakeholders.
04/08/2011
74
Interviews in practice
Normally a mix of closed and open-ended interviewing. Interviews are good for getting an overall understanding of what stakeholders do and how they might interact with the system.
Interviews are not good for understanding domain requirements Requirements engineers cannot understand specific domain terminology; Some domain knowledge is so familiar that people find it hard to articulate or think that it isnt worth articulating.
04/08/2011
75
Effective interviewers
Interviewers should be open-minded, willing to listen to stakeholders and should not have pre-conceived ideas about the requirements. They should prompt the interviewee with a question or a proposal and should not simply expect them to respond to a question such as what do you want.
04/08/2011
76
Scenarios
Scenarios are real-life examples of how a system can be used. They should include A description of the starting situation; A description of the normal flow of events; A description of what can go wrong; Information about other concurrent activities; A description of the state when the scenario finishes.
04/08/2011
77
04/08/2011
78
04/08/2011
79
Use cases
Use-cases are a scenario based technique in the UML which identify the actors in an interaction and which describe the interaction itself. A set of use cases should describe all possible interactions with the system. Sequence diagrams may be used to add detail to use-cases by showing the sequence of event processing in the system.
04/08/2011
80
04/08/2011
81
04/08/2011
82
04/08/2011
83
04/08/2011
84
Requirements validation
Concerned with demonstrating that the requirements define the system that the customer really wants. Requirements error costs are high so validation is very important Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error.
04/08/2011
85
Requirements checking
Validity. Does the system provide the functions which best support the customers needs? Consistency. Are there any requirements conflicts? Completeness. Are all functions required by the customer included? Realism. Can the requirements be implemented given available budget and technology Verifiability. Can the requirements be checked?
04/08/2011
86
04/08/2011
87
Requirements reviews
Regular reviews should be held while the requirements definition is being formulated. Both client and contractor staff should be involved in reviews. Reviews may be formal (with completed documents) or informal. Good communications between developers, customers and users can resolve problems at an early stage.
04/08/2011
88
Review checks
Verifiability. Is the requirement realistically testable? Comprehensibility. Is the requirement properly understood? Traceability. Is the origin of the requirement clearly stated? Adaptability. Can the requirement be changed without a large impact on other requirements?
04/08/2011
89
Requirements management
Requirements management is the process of managing changing requirements during the requirements engineering process and system development. Requirements are inevitably incomplete and inconsistent
New requirements emerge during the process as business needs change and a better understanding of the system is developed; Different viewpoints have different requirements and these are often contradictory.
04/08/2011
90
Requirements change
The priority of requirements from different viewpoints changes during the development process. System customers may specify requirements from a business perspective that conflict with end-user requirements. The business and technical environment of the system changes during its development.
04/08/2011
91
Requirements evolution
04/08/2011
92
04/08/2011
93
Requirements classification
Requirement Type Mutable requirements Emergent requirements Consequential requirements Compatibility requirements Description Requirements that change because of changes to the environment in which the organisation is operating. For example, in hospital systems, the funding of patient care may change and thus require diffe rent treatment info rmation to be collected. Requirements that emerge as the customer's understanding of the system develops during the system development. The design process may reveal new emergent requirements. Requirements that result from the introduction of the computer system. Introducing the computer system may change the organisations processes and open up new ways of working which generate new system requirements Requirements that depend on the particular systems or business processes within an organisation. As these change, the compatibility requirements on the commissioned or delivered system may also have to evolve.
04/08/2011
94
Traceability policies
o The amount of information about requirements relationships that is maintained;
04/08/2011
95
Traceability
Traceability is concerned with the relationships between requirements, their sources and the system design Source traceability
Links from requirements requirements; to stakeholders who proposed these
Requirements traceability
Links between dependent requirements;
Design traceability
Links from the requirements to the design;
04/08/2011
96
A traceability matrix
Req. id 1.1 1.2 1.3 2.1 2.2 2.3 3.1 3.2 1.1 1.2 D R R R D R R 1.3 R D R D D D 2.1 2.2 2.3 D 3.1 3.2 D
04/08/2011
97