Engineering
Requirements Software Analysis and Specification
Analysis: Methodologies
Specification: levels of formality
Informal specification Based on natural language (ambiguous) Formal specification Based on mathematical language Semi-formal specification Made of both informal and formal parts
Specification of data (static view) Specification of behaviour (dynamic view)
P. Lago - Politecnico di Torino
No scientific methods Guidelines, general principles and empirical techniques Too many Subjective factors, Human-related factors, and Communication issues
Analysis should identify A representation of relevant information A model of software behaviour Analysis should consider how the system Will be structured (from the user perspective) Will provide functionality For complex systems, they must be partitioned hierarchically Analysis is then carried out separately on different parts
Use Case Diagram
Activities for Analysis and Requirements Capture Study of the application domain Identification of boundaries and interactions among the application and the external world Identification/Comprehension of requirements Activities for Requirements Specification Requirements specification (based on WHAT and not HOW) Validation/Verification of requirements specification Note: the boundary between analysis and specification is often confused
Requirements Analysis and Specification
Analysis: Guidelines
Specification: types
1
Software Engineering
Specification: styles (behaviour)
Use Case Diagram
Semi-formal notation Specifies the interactions between the system and the external world Useful to Oblige the analyst to state well-defined boundaries between system and external world Organize system functions into elements (use cases) on which attention is focused Supply a first basis for the specification of system structure from the user perspective
Operational It specifies the procedures Example: List B is obtained from list A by moving the smallest element in A in the first position of B, the new smallest element in A in the second position of B, and so forth until list A is empty. Descriptive It specifies the properties Example: list B is the ordered permutation of list A
Elements of a Use Case Diagram
Actor
Relations among Use Cases
1 *
Someone (user) or something (external system, hardware) that Exchanges information with the system Supplies input to the system, or receives output from the system
Use Case Actor
Use Case Actor
Association. Models: Which actors participate in a use case Where execution starts Adornments (e.g. multiplicity, direction) allowed
Use Case
A functional unit (functionality) part of the system
Use Case Actor
<<include>> Use Case A Use Case B
Include. Models that functionality A is used in the context of functionality B (one is a phase of the other)
Relations among Use Cases
Use Case A Use Case B
Relations among Use Cases
Extension. An extend relationship from use case B to use case A indicates that an instance of use case A may be augmented by the behavior specified by B The behavior is inserted at the location defined by the extension point in A
Generalization. Defines functionality B as a specialization of functionality A (e.g. a special case)
Use Case C <<include>> Use Case B
1
*
<<extend>>
SalesPerson
Place Order
Generalization. A generalization from an actor B to an actor A indicates that an instance of B can communicate with the same kinds of use-case instances as an instance of A
Extension points further func of b: after C
Use Case A
1
*
Supervisor
Establish Credit
P. Lago - Politecnico di Torino
2
Software Engineering
At the beginning of the semester, the office students has to supply the students with the list of available courses through a system of online registration. Each student must select 4 available courses, and state two possible alternatives. Each course must have from 3 to 20 students: courses with less than 3 students are cancelled, and those with more than 20 are split. In the previous period, the professors access the system online to insert their courses in the list, while in the period after students' selection they access to check current state of enrolled students to their courses. After the selection period, the system creates def. lists, by solving all anomalies (courses with less than 3 or more than 20 selections) and it sends them to administrative office to state enrolment charges due by each student. The students access the system for the list of their courses All user interactions are authenticated
Online Courses
UCD for Online Courses
Administrative Office
Course Selection <<include>>
Request Students List <<include>>
<<include>> Students
User Authentication <<include>>
Professor
Request Course List
Insert Course
Domestic Security System
Once installed, the system monitors all connected sensors (of movement, entrance, smoke), and interacts with the user though a keyboard and a display inside a dedicated control panel. During installation, the control panel is used to configure the system. Each sensor is assigned with a unique numeric code and the phone number of the monitoring service to call in case of events related with a sensor. It also defines a password for activate/deactivate the system. In case of an event related with some sensors, the system displays a message and produces an acoustic alarm. After a period (defined during user configuration) the system calls the phone number associated with the sensor. Should the number be busy, the system repeats the call every 20 seconds.
UCD for Domestic Security System
<<include>> Set password User Configuration <<include>> Configure sensor
Sensor
Event management Acoustic Transmitter
Monitoring Service
Room booking
Un sistema di prenotazione di un hotel deve permettere ad un cliente di riservare una stanza Il sistema de...