Caburian, John Joshua Q.

Dela Pea, Karen Kate

Yan, Jimaria Gwen N.
Samala, John Kenneth D.

December 5, 2016
Software Engineering
Prof. Arlyn Orense

Requirements Design
1. Design Notation: Modeling and Languages

To
illustrate this process of design elaboration, consider software to be built for a
sophisticated print shop. The overall intent of the software is to collect the
customers requirements at the front counter, cost a print job, and then pass the job
on to an automated production facility. During requirements engineering, an
analysis class called PrintJob was derived. The attributes and operations defined
during analysis are noted at the top of Figure 10.1. During architectural design,
PrintJob is defined as a component within the software architecture and is
represented using the shorthand UML notation2 shown in the middle right of the
figure. Note that PrintJob has two interfaces, computeJob, which provides job costing
capability, and initiateJob, which passes the job along to the production facility.
These are represented using the lollipop symbols shown to the left of the
component box.

In the context of traditional software engineering, a component is a functional

element of a program that incorporates processing logic, the internal data
structures that are required to implement the processing logic, and an interface that
enables the component to be invoked and data to be passed to it. A traditional
component, also called a module, resides within the software architecture and
serves one of three important roles: (1) a control component that coordinates the
invocation of all other problem domain components, (2) a problem domain
component that implements a complete or partial function that is required by the
customer, or (3) an infrastructure component that is responsible for functions that
support the processing required in the problem domain.

2. Architecture Models

3. Screen Design
Software User Interface Design
User interface is the front-end application view to which user interacts in order to
use the software. User can manipulate and control the software as well as hardware
by means of user interface. Today, user interface is found at almost every place
where digital technology exists, right from computers, mobile phones, cars, music
players, airplanes, ships etc.

User interface is part of software and is designed such a way that it is expected to
provide the user insight of the software. UI provides fundamental platform for
human-computer interaction.
UI can be graphical, text-based, audio-video based, depending upon the underlying
hardware and software combination. UI can be hardware or software or a
combination of both.
The software becomes more popular if its user interface is:

Attractive

Simple to use

Responsive in short time

Clear to understand

Consistent on all interfacing screens

UI is broadly divided into two categories:

Command Line Interface

Graphical User Interface

Command Line Interface (CLI)

CLI has been a great tool of interaction with computers until the video display
monitors came into existence. CLI is first choice of many technical users and
programmers. CLI is minimum interface a software can provide to its users.
CLI provides a command prompt, the place where the user types the command and
feeds to the system. The user needs to remember the syntax of command and its
use. Earlier CLI were not programmed to handle the user errors effectively.
A command is a text-based reference to set of instructions, which are expected to
be executed by the system. There are methods like macros, scripts that make it
easy for the user to operate.
CLI uses less amount of computer resource as compared to GUI.

Graphical User Interface

Graphical User Interface provides the user graphical means to interact with the
system. GUI can be combination of both hardware and software. Using GUI, user
interprets the software.

Typically, GUI is more resource consuming than that of CLI. With advancing
technology, the programmers and designers create complex GUI designs that work
with more efficiency, accuracy and speed.
Defining Usability
Ease of Use
Usability is a measure of how easy it is to use a product to perform prescribed tasks.
This is distinct from the related concepts of utility and likeability.
Usability vs. Utility
A central attribute that determines a products acceptability is usefulness, which
measures whether the actual uses of a product can achieve the goals the designers
intend them to achieve. The concept of usefulness breaks down further into utility
and usability. Although these terms are related, they are not interchangeable.
Utility refers to the ability of the product to perform a task or tasks. The more tasks
the product is designed to perform, the more utility it has.
Consider typical Microsoft MS-DOS word processors from the late 1980s. Such
programs provided a wide variety of powerful text editing and manipulation
features, but required users to learn and remember dozens of arcane keystrokes to
perform them. Applications like these can be said to have high utility (they provide
users with the necessary functionality) but low usability (the users must expend a
great deal of time and effort to learn and use them). By contrast, a well-designed,
simple application like a calculator may be very easy to use but not offer much
utility.
Both qualities are necessary for market acceptance, and both are part of the overall
concept of usefulness. Obviously, if a program is highly usable but doesnt do
anything of value, nobody will have much reason to use it. And users who are
presented with a powerful program that is difficult to use will likely resist it or seek
out alternatives.
Usability testing helps you determine how easy it is for users to perform particular
tasks. However, it does not directly help you determine if the product itself has
value or utility. (Users may volunteer utility-related comments during usability
testing, but any comments should be verified with other, more robust research
methods.)
Liking It vs. Using It
Likeability is always a desirable trait in a product. If people like the product, they are
more likely to use it and to recommend it to others. But as with utility, you should
be careful not to confuse likeability with usability.

People often like a product for reasons unrelated to utility and usability. They may
be attracted to its styling and flash, or to the status they believe the product
confers upon them. People tend to like highly usable products, but you should not
assume that means a well-liked product is usable.
Usability is about whether a person can use the product to perform the tasks they
need to perform. Usability testing primarily measures performance, not preference.
However, standardized questionnaires can be used to measure preference across
products.
Discovery vs. Learning vs. Efficiency
There are many aspects to usability, but traditionally the term refers specifically to
the attributes of discovery, learning, and efficiency.
Discovery involves looking for, and finding, a products feature in response to a
particular need. Usability testing can determine how long it takes a user to find a
feature and how many errors (wrong choices about location) the user makes along
the way.
Learning refers to the process by which the user figures out how to use a discovered
feature to complete the task at hand. Usability testing can determine how long this
process takes as well as how many errors the user makes while learning the feature.
Efficiency refers to the point at which the user has mastered the feature and uses
it without requiring further learning. Usability testing can determine how long it
takes for the experienced user to execute the steps necessary to use the feature.
These three basic aspects of usability are strongly influenced by the nature of the
task at hand and the frequency with which the user performs it. Some features are
used so seldom or are so complex that the user essentially relearns them every
time; for these features, Microsoft often develops wizards to guide the user through
the process.
4. Design Patterns

5.

Documentation
Software documentation is written text or illustration that accompanies
computer software. It either explains how it operates or how to use it, and may
mean different things to people in different roles.
Documentation is an important part of software engineering. Types of
documentation include:
1. Requirements Statements that identify attributes, capabilities,
characteristics, or qualities of a system. This is the foundation for what will be
or has been implemented.

2. Architecture/Design Overview of software. Includes relations to an

environment and construction principles to be used in design of software
components.
3. Technical Documentation of code, algorithms, interfaces, and APIs.
4. End user Manuals for the end-user, system administrators and support staff.
5. Marketing How to market the product and analysis of the market demand.
Requirements documentation
Requirements documentation is the description of what a particular software
does or shall do. It is used throughout development to communicate how the
software functions or how it is intended to operate. It is also used as an
agreement or as the foundation for agreement on what the software will do.
Requirements are produced and consumed by everyone involved in the
production of software: end users, customers, product managers, project
managers, sales, marketing, software architects, usability engineers, interaction
designers, developers, and testers, to name a few. Thus, requirements
documentation has many different purposes.
Requirements come in a variety of styles, notations and formality. Requirements
can be goal-like (e.g., distributed work environment), close to design (e.g., builds
can be started by right-clicking a configuration file and select the 'build'
function), and anything in between. They can be specified as statements in
natural language, as drawn figures, as detailed mathematical formulas, and as a
combination of them all.
The variation and complexity of requirements documentation makes it a proven
challenge. Requirements may be implicit and hard to uncover. It is difficult to
know exactly how much and what kind of documentation is needed and how
much can be left to the architecture and design documentation, and it is difficult
to know how to document requirements considering the variety of people who
shall read and use the documentation. Thus, requirements documentation is
often incomplete (or non-existent). Without proper requirements documentation,
software changes become more difficult and therefore more error prone
(decreased software quality) and time-consuming (expensive).
The need for requirements documentation is typically related to the complexity
of the product, the impact of the product, and the life expectancy of the
software. If the software is very complex or developed by many people (e.g.,
mobile phone software), requirements can help to better communicate what to
achieve. If the software is safety-critical and can have negative impact on human
life (e.g., nuclear power systems, medical equipment, mechanical equipment),
more formal requirements documentation is often required. If the software is
expected to live for only a month or two (e.g., very small mobile phone
applications developed specifically for a certain campaign) very little
requirements documentation may be needed. If the software is a first release

that is later built upon, requirements documentation is very helpful when

managing the change of the software and verifying that nothing has been broken
in the software when it is modified.
Traditionally, requirements are specified in requirements documents (e.g. using
word processing applications and spreadsheet applications). To manage the
increased complexity and changing nature of requirements documentation (and
software documentation in general), database-centric systems and specialpurpose requirements management tools are advocated.

6. Risk Management
Seven Principles of Risk Management
The Software Engineering Institute (SEI) (www.sei.cmu.edu) identifies seven
principles that provide a framework to accomplish effective risk management.
They are:
Maintain a global perspectiveview software risks within the context of a
system in which it is a component and the business problem that it is intended to
solve
Take a forward-looking viewthink about the risks that may arise in the future
(e.g., due to changes in the software); establish contingency plans so that future
events are manageable.
Encourage open communicationif someone states a potential risk, dont
discount it. If a risk is proposed in an informal manner, consider it. Encourage all
stakeholders and users to suggest risks at any time.
Integratea consideration of risk must be integrated into the software process.
Emphasize a continuous processthe team must be vigilant throughout the
software process, modifying identified risks as more information is known and
adding new ones as better insight is achieved.
Develop a shared product visionif all stakeholders share the same vision of
the software, it is likely that better risk identification and assessment will occur.
Encourage teamworkthe talents, skills, and knowledge of all stakeholders
should be pooled when risk management activities are conducted