Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

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)

375 documents

1 / 29

Toggle sidebar

Related documents


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: Useful Texts

Grady Booch, James Rumbaugh, Ivar Jacobson, The Unified Modeling Language. Addison-Wesley 1999. The next few slides are based on the approach taken in this book (BRJ). Grady Booch, et al., Object-Oriented Analysis and Design with Applications , third edition. Benjamin/Cummings 2007. Rob Pooley, Perdita Stevens, Using UML Software Engineering with Objects and Components , second edition. Addison-Wesley 2005.

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

The Unified Modeling Language

UML is a standard language for modeling software systems

  • Serves as a bridge between the requirements specification and the implementation.
  • Provides a means to specify and document the design of a software system.
  • Is process and programming language independent.
  • Is particularly suited to object-oriented program development.

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 Models

External enBBes Processing steps Data stores or sources Data flows An informal modeling technique to show the flow of data through a system.

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?

Data-Flow Model

Example: Process Completed Application

Rejection Evaluation Applicant database Evaluation request Acceptance Financial aid Offer Special request The requirements will need a description of the decision-making process.

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.

Flowchart Model

Example: University Admissions Assemble Application

Form received New applicant? New database record

T

Notify student F Update database Application complete? Notify student

T

F

Evaluate Compare this example, which shows the logic, with the dataflow model, which shows the flow of data.

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

0

0

0

Example: Radia1on Therapy Control Console You are developing requirements for the operator's control console. In an interview, the client describes the procedures that the operator must follow when operaBng the machine. You use a finite state machine model to specify the procedures. This shows the client that you understand the requirements and specifies the procedures for the developers. This scenario and state diagram are based on a published example. Unfortunately I have no record of the source. If you know it, please contact me so that I can acknowledge the author.

Finite State Machine Model

Therapy Control Console

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.

Finite State Machine Model

State TransiBon Table

Select PaOent Select Field Enter lock off^ Start Stop lock on PaBents Fields Setup Ready Beam on Fields Fields Fields PaBents PaBents PaBents Setup Setup Setup Ready Beam on Ready This table can be used for requirements definiBon, program design, and acceptance tesBng.

TransiBon Diagram for User Interfaces

Example: CS 5150 Web Site (part)

home lectures (^) projects books assign- ments tests integrity^ about course materials sample reports sugges- Oons examples scripts

EnBty-RelaBon Model

A requirements and design methodology for rela1onal databases

  • A database of enBBes and relaBons
  • Tools for displaying and manipulaBng enBty-relaBon diagrams
  • Tools for manipulaBng the database (e.g., as input to database design) EnBty-relaBonship models can be used both for requirements specificaBon and for the design specificaBon.

Modeling Tools: EnBty-RelaBon Diagram

An enBty (noun) A relaBon between enBBes (verb) An enBty or relaBon airibute Note: There are various notaOons used for enOty-relaOonship diagrams. This is the notaOon used by Chen (1976).

Modeling Tools: EnBty RelaBonship Diagram

Example: CS 5150 Project

CS 5150

Student Major Project 6 to 8

IsMember Client team member IsClient 1 IsContact 0:n 1