Models for Requirements Analysis and Specification in Software Engineering, Lecture notes of Software Engineering

The use of models in analyzing and specifying requirements in software engineering. It emphasizes the importance of selecting the appropriate tool for the task and provides an overview of various tools and techniques. The Unified Modeling Language (UML) is introduced as a standard language for modeling software systems. The document also includes examples of data-flow models and flowchart models for university admissions. likely to be useful as study notes or lecture notes for a software engineering course.

Typology: Lecture notes

2022/2023

Uploaded on 05/11/2023

arold
arold 🇺🇸

4.7

(24)

372 documents

1 / 29

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
Cornell'University!
Compu1ng'and'Informa1on'Science
CS#5150#So(ware#Engineering#
8.##Models#for#Requirements#Analysis##
and#SpecificaBon#
William#Y.#Arms
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff
pf12
pf13
pf14
pf15
pf16
pf17
pf18
pf19
pf1a
pf1b
pf1c
pf1d

Partial preview of the text

Download Models for Requirements Analysis and Specification in Software Engineering and more Lecture notes Software Engineering in PDF only on Docsity!

Cornell University

Compu1ng and Informa1on Science

CS 5150 So(ware Engineering

8. Models for Requirements Analysis

and SpecificaBon

William Y. Arms

Models for Requirements Analysis and Specification

As you build understanding of the requirements through viewpoint analysis, scenarios, use cases, etc., use models to analyze and specify requirements. The models provide a bridge between the client's understanding and the developers'. The craft of requirements analysis and specification includes selecting the appropriate tool for the particular task.

  • A variety of tools and techniques.
  • Many familiar from other courses.
  • No correct technique that fits all situations.

Models

A model is a simplification of reality

  • We build models so that we can better understand the system we are developing.
  • We build models of complex system because we cannot comprehend such a system in its entirety. Models can be informal or formal. The more complex the project the more valuable a formal model becomes. BRJ

Principles of Modeling

  • The choice of what models to create has a profound influence on how a problem is attacked and how a solution is shaped.
  • No single model is sufficient. Every nontrivial system is best approached through a small set of nearly independent models.
  • Every model can be expressed at different levels of precision.
  • Good models are connected to reality. BRJ

Rational Rose

Rational Rose is an IBM-owned system for creating and managing UML models (diagrams and specifications).

Models: Diagrams and Specification in UML

In UML, a model consists of a diagram and a specification.

  • A diagram is the graphical representation of a set of elements, usually rendered as a connected graph of vertices (things) and arcs (relationships).
  • Each diagram is supported by technical documentation that specifies in more detail the model represented by the diagram. A diagram without a specification is of little value.

Data-Flow Model

Example: University Admissions (first attempt)

Applicant Application form Assemble application Completed application Evaluate Rejection Acceptance Shows the flow, but where is the data stored? Is there supporting information?

Data-Flow Model

Example: Assemble ApplicaBon

Applicant ApplicaBon form Receive documents Completed applicaBon SupporBng documents Pending database Acknowledgment Begin evaluaBon Applicant database EvaluaBon request

AND

AND

Acknowledgment Does this model cover all situaBons? Are there special cases?

Decision Table Model

University Admission Decision Each column is a separate decision case. The columns are processed from left to right. Note that the rules are specific and testable.

SAT > S1 T F F F F F

GPA > G1 - T F F F F

SAT between S1 and S2 - - T T F F GPA between G1 and G2 - - T F T F Accept X X X Reject X X X

Flowchart Models

Operation Decision Manual operation Report An informal modeling technique to show the logic of part of a system and paths that data takes through a system.

Modeling Tools: Pseudo-code

An informal modeling technique to show the logic behind part of a system. Example: University Admission Decision admin_decision (application) if application.SAT == null then error (incomplete) if application.SAT > S1 then accept(application) else if application.GPA > G1 then accept(application) else if application.SAT > S2 and application.GPA > G then accept(application) else reject(application) The notation used for pseudo-code can be informal, or a standard used by a software development organization, or based on a regular programming language. What matters is that its interpretation is understood by everybody involved.

Modeling Tools: TransiBon Diagrams

A system is modeled as a set of states , S i A transi1on is a change from one state to another. The occurrence of a condi1on , C i , causes the transiBon from one state to another Transi1on func1on : f ( S i

, C

j

) = S

k Example

S

1 S 2

S

3

Finite State Machine Model

Therapy Control Console: Scenario

Scenario The client provides the following rough scenario. "The set up is carried out before the paBent is made ready. The operator selects the paBent informaBon from a database. This provides a list of radiaBon fields that are approved for this paBent. The operator selects the first field. This completes the set up. "The paBent is now made ready. The lock is taken off the machine and the doses with this field are applied. The operator then returns to the field selecBon and chooses another field."

Finite State Machine Model

State TransiBon Diagram

PaBents (^) Fields Setup Ready Beam on [Enter] [Enter] [Start] [Stop] [Select field] [Select paOent] [lock on] [lock off] Discuss each state and transiBon with the client.