Introduction.

Requirements
Engineering.
Basics of Use
Cases
Yemberdiyeva Aknur
Bakytbekkyzy
Assistant , MSc
Course description
• This course lays a solid foundation upon which solutions for these much larger and more
important applications may be built. Students will study large systems and how they were
partitioned into subsystems and components, as well as how the structuring of these
elements into a solution and the interfaces used to join them together facilitates
communication and control. Students will explore with various notations and formalisms
as they learn the relationship between these structures and key quality attributes and their
impact on system implementation. Differences between detailed design and architecture
are explored, as well as notations used for both. Two major applications are analyzed and
the impact of several wellknown architectural styles is evaluated. The use of various
notations is explored, with a focus on UML, and the role of architecture and detailed
design specifications are considered from the perspective of risk management.
 Period Assignments Maximum Total

Student
score
1st
laboratory works: 100
attestatio LW 1 100

performan n LW 2
LW 3
Mid-term(Part1)
100
100
100
100

ce 2
Mid-term(Part2)

laboratory works:
100

100

evaluation
nd

attestatio LW 4 100
n LW 5 100
LW 6 100 100
system for End of term (Part1)
End of term (Part2)
100
100

the course Final

exam
Project 100

Total 100
Attendance
• If the number of absences exceeds 20%, student will be automatically scheduled for a
Retake
What is software
architecture ?
The software architecture of a
system represents the design decisions
related to overall system structure and
behavior. Architecture helps
stakeholders understand and analyze
how the system will achieve essential
qualities such as modifiability,
availability, and security.
• Software developers wield some
tangible weapons, such as
Integrated Development
Environments (IDEs) and
programming languages, but
intangible weapons arguably
make a bigger impact.
Software is similar in that there are lots of low-level details. If developers have
built up a set of mental abstractions (i.e., a conceptual model), they can convert those
details into a condensed understanding: where before they saw just code, perhaps
they now see a thread-safe locking policy or an event-driven system.
• The comparison between software design and (civil)
architecture was first drawn in the late 1960s, but the term
"software architecture" did not see widespread usage until the
1990s.The field of computer science had encountered
problems associated with complexity since its
formation. Earlier problems of complexity were solved by
developers by choosing the right data structures, developing
algorithms, and by applying the concept of
separation of concerns. Although the term "software
architecture" is relatively new to the industry, the fundamental
principles of the field have been applied sporadically by
software engineering pioneers since the mid-1980s. Early
attempts to capture and explain software architecture of a
system were imprecise and disorganized, often characterized
by a set of box-and-line diagrams.
• Software architecture as a concept has its origins in the
research of Edsger Dijkstra in 1968 and David Parnas in the
early 1970s. These scientists emphasized that the structure of a
software system matters and getting the structure right is
critical. During the 1990s there was a concerted effort to define
and codify fundamental aspects of the discipline, with research
work concentrating on architectural styles (patterns),
architecture description languages, architecture documentation,
and formal methods.
• Research institutions have played a prominent role in furthering
software architecture as a discipline. Mary Shaw and
David Garlan of Carnegie Mellon wrote a book titled Software
Architecture: Perspectives on an Emerging Discipline in 1996,
which promoted software architecture concepts such as
components, connectors, and styles. The
University of California, Irvine's Institute for Software
Research's efforts in software architecture research is directed
primarily in architectural styles, architecture description
languages, and dynamic architectures.
• Software architecture supporting activities are carried out during
core software architecture activities. These supporting activities
assist a software architect to carry out analysis, synthesis,
evaluation, and evolution. For instance, an architect has to
gather knowledge, make decisions, and document during the
analysis phase.
• Knowledge management and communication is the act of exploring and
managing knowledge that is essential to designing a software architecture. A
software architect does not work in isolation. They get inputs, functional and
non-functional requirements, and design contexts, from various stakeholders;
and provide outputs to stakeholders. Software architecture knowledge is often
tacit and is retained in the heads of stakeholders. Software architecture
knowledge management activity is about finding, communicating, and retaining
knowledge. As software architecture design issues are intricate and
interdependent, a knowledge gap in design reasoning can lead to incorrect
software architecture design. Examples of knowledge management and
communication activities include searching for design patterns, prototyping,
asking experienced developers and architects, evaluating the designs of similar
systems, sharing knowledge with other designers and stakeholders, and
documenting experience on a wiki page.
• Design reasoning and decision making is the activity of evaluating
design decisions. This activity is fundamental to all three core software
architecture activities. It entails gathering and associating decision
contexts, formulating design decision problems, finding solution
options and evaluating tradeoffs before making decisions. This process
occurs at different levels of decision granularity while evaluating
significant architectural requirements and software architecture
decisions, and software architecture analysis, synthesis, and
evaluation. Examples of reasoning activities include understanding the
impacts of a requirement or a design on quality attributes, questioning
the issues that a design might cause, assessing possible solution
options, and evaluating the tradeoffs between solutions.
• Documentation is the act of recording the design generated during the
software architecture process. System design is described using several
views that frequently include a static view showing the code structure of
the system, a dynamic view showing the actions of the system during
execution, and a deployment view showing how a system is placed on
hardware for execution. Kruchten's 4+1 view suggests a description of
commonly used views for documenting software
architecture; Documenting Software Architectures: Views and Beyond has
descriptions of the kinds of notations that could be used within the view
description. Examples of documentation activities are writing a
specification, recording a system design model, documenting a design
rationale, developing a viewpoint, documenting views.
Partitioning, knowledge,
and abstractions

• To be successful at combating the scale and

complexity of software in the next decade,
developers will need improved weapons. Those
weapons can be categorized, perhaps with a bit of
shoehorning, into three categories: partitioning,
knowledge, and abstraction. Developers partition a
problem so that its parts are smaller and more
tractable, they apply knowledge of similar
problems, and they use abstractions to help them
reason. Partitioning, knowledge, and abstraction
are effective because they enable our fixed-sized
minds to comprehend an ever-growing problem.
• • Partitioning. Partitioning is effective as a strategy to combat complexity and scale when
two conditions are true: first, the divided parts must be sufficiently small that a person
can now solve them; second, it must be possible to reason about how the parts
assemble1 into a whole. Parts that are encapsulated are easier to reason about, because
you need to track fewer details when composing the parts into a solution. You can forget,
at least temporarily, about the details inside the other parts. This allows the developer to
more easily reason about how the parts will interact with each other
• Knowledge. Software developers use knowledge of prior problems to
help them solve current ones. This knowledge can be implicit know-
how or explicitly written down. It can be specific, as in which
components work well with others, or general, as in techniques for
optimizing a database table layout. It comes in many forms, including
books, lectures, pattern descriptions, source code, design documents,
or sketches on a whiteboard.
• Abstraction. Abstraction can effectively
combat complexity and scale because it
shrinks problems, and smaller problems
are easier to reason about. If you are
driving from New York to Los Angeles, you
can simplify the navigation problem by
considering only highways. By hiding
details (excluding the option of driving
across fields or parking lots), you have
shrunken the number of options to
consider, making the problem easier to
reason about.
• You should not expect any silver bullets, as Fred Brooks called them, that will suddenly
eliminate the difficulties of software development (Brooks, 1995). Instead, you should
look for weapons that help you partition systems better, provide knowledge, and enable
abstraction to reveal the essence of the problem.
• Software architecture is one such weapon and it can help you address the complexity and
scale of software systems. It helps you partition software, it provides knowledge that
helps you design better software, and it provides abstractions that help you reason about
software. It is a tool in the hands of a skilled developer. It helps software developers to
routinely build systems that previously required virtuosos (Shaw and Garlan, 1996), but it
does not eliminate the need for skilled software developers. Instead of removing the
need for ingenuity, it allows developers to apply their ingenuity to build bigger and more
complex systems.
Three examples of
software architecture
• Rackspace is a real company that manages hosted email
servers. Customers call up for help when they experience
problems. To help a customer, Rackspace must search
the log files that record what has happened during the
customer’s email processing. Because the volume of
emails they handle kept increasing, Rackspace built three
generations of systems to handle the customer queries
(Hoff, 2008b; Hood, 2008).
• Version 1: Local log files. The first version of the program
was simple. There were already dozens of email servers
generating log files. Rackspace wrote a script that would
use ssh to connect to each machine and execute a grep
query on the mail log file. Engineers could control the
search results by adjusting the grep query. This version
initially worked well, but over time the number of
searches increased and the overhead of running those
searches on the email servers became noticeable. Also,
it required an engineer, rather than a support tech, to
perform the search.
• Version 2: Central database. The second version addressed the
drawbacks of the first one by moving the log data off of the email servers
and by making it searchable by support techs. Every few minutes, each
email server would send its recent log data to a central machine where it
was loaded into a relational database. Support techs had access to the
database data via a web-based interface. Rackspace was now handling
hundreds of email servers, so the volume of log data had increased
correspondingly. Rackspace’s challenge became how to get the log data
into the database as quickly and efficiently as possible. The company
settled on bulk record insertion into merge tables, which enabled loading
of the data in two or three minutes. Only three days worth of logs were
kept so that the database size would not hinder performance.
• Over time, this system also encountered problems. The
database server was a single machine and, because of
the constant loading of data and the query volume, it
was pushed to its limit with heavy CPU and disk loads.
Wildcard searches were prohibited because of the extra
load they put on the server. As the amount of log data
grew, searches became slower. The server experienced
seemingly random failures that became increasingly
frequent. Any log data that was dropped was gone
forever because it was not backed up. These problems
led to a loss of confidence in the system.
• Version 3: Indexing cluster. The third version addressed
the drawbacks of the second by saving log data into a
distributed file system and by parallelizing the indexing
of log data. Instead of running on a single powerful
machine, it used ten commodity machines. Log data
from the email servers streamed into the Hadoop
Distributed File System, which kept three copies of
everything on different disks. In 2008, when Rackspace
wrote a report on its experiences, it had over six
terabytes of data spanning thirty disk drives, which
represented six months of search indexes.
• Indexing was performed using Hadoop, which divides the input data, indexes (or “maps”)
in jobs, then combines (or “reduces”) the partial results into a complete index. Jobs ran
every ten minutes and took about five minutes to complete, so index results were about
fifteen minutes stale. Rackspace was able to index over 140 gigabytes of log data per day
and had executed over 150,000 jobs since starting the system.
• The first thing to notice from looking at these three
systems is that they all have roughly the same
functionality (querying email logs to diagnose problems)
yet they have different architectures. Their architecture
was a separate choice from their functionality. This
means that when you build a system, you can choose an
architecture that best suits your needs, then build the
functionality on that architectural skeleton.
• Quality attributes. Despite having the same functionality, the three systems differ in their
modifiability, scalability, and latency. For example, in the first and second version, ad hoc
queries could be created in a matter of seconds, either by changing the grep expression
used for the search or by changing the SQL query. The third system requires a new
program to be written and scheduled before query results can be obtained. All three
support creating new queries, but they differ in how easy it is to do (modifiability).
• Conceptual model. Even without being a software
architecture expert, you could read about these three
systems and reason about their design from first
principles. What advantage would come from being a
software architecture expert (i.e., being a coach instead
of a rookie)? Both coaches and rookies have an innate
ability to reason, but the coach has a head start because
of the conceptual model he carries in his head that helps
him make sense of what he sees.
• Abstractions and constraints. In software, bigger things are usually built out of smaller
things. You can always reason about the smaller things in a system (like individual lines of
code) but usually you will find it more efficient to reason about the larger things (like
clients and servers). For example, the third system in the Rackspace example scheduled
jobs and stored data in a distributed file system. If you needed to solve a problem about
how jobs flow through that system, then it would be most efficient to reason about the
problem at that level. You could begin your reasoning process by considering the small
bits, like objects and procedure calls, but that would be inefficient and likely to swamp
you with details.
• New architecture abstractions rarely replace old abstractions, but instead coexist with them.
Using abstractions such as components and connectors does not mean that objects, methods,
and data structures disappear. Similarly, forest fire fighters switch between thinking about
individual trees or entire forests depending on what part of their job they are doing at the
moment. Effectively applying software architecture ideas requires a conscious and explicit shift to
embrace its abstractions, such as components and connectors, rather than only using the
abstractions found in mainstream programming language (often just classes or objects). If you do
not consciously choose the architecture of your systems, then it may end up being what Brian
Foote and Joseph Yoder call a big ball of mud (Foote and Yoder, 2000), which they estimate is the
most common software architecture. It is easy to understand this architecture: Imagine what a
system with 10 classes would look like, then scale it up to 100, 1000, ..., without any new
abstractions or partitions, and let the objects in the system communicate with each other as is
expedient.
• Job titles, development processes, and engineering artifacts are separable, so it is
important to avoid conflating the job title “architect,” the process of architecting a
system, and the engineering artifact that is the software architecture.
• The job role: architect. One possible job title (or role) in an organization is that of a
software architect. Some architects sit in corner offices and make pronouncements that
are disconnected from the engineering reality, while other architects are intimately
involved in the ongoing construction of the software Either way, the title and the office
are not intrinsic to the work of designing or building software. All software developers,
not just architects, should understand their software’s architecture.
• The process: architecting. There is no software at
the beginning of a project, but by the end of the
project there is a running system. In between, the
team performs activities (i.e., they follow a
process) to construct the system. Some teams
design up-front and other teams design as they
build. The process that the team follows is
separable from the design that emerges. A team
could follow any number of different processes and
produce, for example, a 3-tier system.
• The engineering artifact: the architecture. If you look at an automobile, you
can tell what type of car it is, perhaps an all-electric car, a hybrid car, or an
internal combustion car. That characteristic of the car is distinct from the
process followed to design it, and distinct from the job titles used by its
designers. The car’s design is an engineering artifact. Different choices
about process and job titles could still result in their creating, for example,
a hybrid car. Software is similar. If you look at a finished software system,
you can distinguish various designs; for example: collaborating peer-to-
peer nodes in a voice-over-IP network, multiple tiers in information
technology (IT) systems, or parallelized map-reduce compute nodes in
internet systems. Every software system has an architecture just as every
car has a design. Some software is cobbled together without a regular
process, yet its architecture is still visible.
Architecture for
agile developers
• Just enough architecture. The risk-driven model of
architecture guides developers to do just enough
architecture then resume coding. If you only foresee risks
on your project that can be handled by refactoring then
you would not do any architecture design. But if you are
an agilist who is also concerned that refactoring may not
be enough to get the security or scalability you need,
now you have a way to mitigate those risks — even in
your Nth iteration — then get back to coding.
• Conceptual model. Agile’s primary contribution is to software development process, not
design abstractions, and offers a limited number of techniques (such as refactoring and
spikes) to produce good designs. The contents of this book augment agile processes by
providing a conceptual model to reason about a system’s architecture and design, a set
of software design and modeling techniques, and expert software architecture
knowledge.
 Software requirments specification.
A software requirements specification (SRS) is a document that
describes what the software will do and how it will be expected to
perform. It also describes the functionality the product needs to fulfill
the needs of all stakeholders (business, users).
• Introduction

• Purpose
• Document conventions
• Intended Audience and Reading Suggestions
• Project scope
• References
• Overall Description

• Product perspective
• Product features
• User classes and characteristics
• Operating environment
• Design and implementation constraints
• User documentation
• Assumptions and dependencies
• System features

• System feature X

• Description and priority

• Stimulus/Response sequences
• Functional requirements
• External interface requirements

• User interfaces
• Software interfaces
• Hardware interfaces
• Communication interfaces
• Non functional requirements

• Performance requirements
• Safety requirements
• Software quality attributes
• Security requirements
• Other requirements
• Appendix A: Glossary
• Appendix B: Analysis Models
• Appendix C: Issues list
Basic requirements for all sections
of the SRS
• Shortly
• No ambiguous descriptions.
• Simplicity and readability.
• DFD diagrams.
• Level of detail.
Use Cases

• A use case is a written description of how users will

perform tasks on your website. It outlines, from a
user’s point of view, a system’s behavior as it
responds to a request. Each use case is
represented as a sequence of simple steps,
beginning with a user's goal and ending when that
goal is fulfilled.
 • Use cases add value because they help
Benefits explain how the system should behave and in
the process, they also help brainstorm what
of Use could go wrong. They provide a list of goals
and this list can be used to establish the cost
and complexity of the system. Project teams
Cases can then negotiate which functions become
requirements and are built.
 What Use Cases Do NOT
What Use Cases Include
Include
•Who is using the website •Implementation-specific
•What the user want to do language
•The user's goal •Details about the user
•The steps the user takes to interfaces or screens.
accomplish a particular task
•How the website should
respond to an action
Elements of a Use Case
Alternative paths
[Alternative Flow] – Depending on how in
these paths are a depth and complex you
variation on the main want or need to get, use
theme. These exceptions cases describe a
are what happen when combination of the
things go wrong at the following elements:
system level.

Main success Actor – anyone or

scenarios [Basic Flow] – anything that performs a
use case in which behavior (who is using
nothing goes wrong. the system)

Stakeholder – someone
Triggers – this is the or something with
event that causes the vested interests in the
use case to be initiated. behavior of the system
under discussion (SUD)

Preconditions – what Primary Actor –

must be true or happen stakeholder who initiates
before and after the use an interaction with the
case runs. system to achieve a goal
example
 •literature:
1. Just Enough Software Architecture: A Risk-Driven Approach by George Fairbanks, Marshall
& Brainerd Publishers, 2010.
2. Sommerville, L. , Software engineering, Ninth Edition / Lan Sommerville.- USA: Pearson,
2011.
3. DAMA-DMBOK: Data Management Body of Knowledge. Ackerman Anderson, Linda and
Dean Anderson. 2017.
•
•Supplementary literature:
1. Richard, H., Software Engineering, The Development Process / H. Richard, M.J.and Thayer
Chiristensen; Edited by: Richard H. and Mark J. Chiristensen. Foreword by: Carl K. Chang.-
Third edition.- Wiley-Interscience, 2005.
2. Len Bass, Paul Charls Clements, Rick Kazman. Software Architecture in Practice. 3 rd
Edition.-Addison-Wesley Professiobal, 2012.-620 p.