UNIT 4 REFINING THE SYSTEM DEFINITION.docx

UNIT 4 REFINING THE SYSTEM DEFINITION
SOFTWARE REQUIREMENT:
According to IEEE standard 729, a requirement is defined as follows:
 A condition or capability needed by a user to solve a problem or achieve an
objective
 A condition or capability that must be met or possessed by a system or
system component to satisfy a contract, standard, specification or other
formally imposed documents
 A documented representation of a condition or capability as in 1 and 2.
Main types of software requirement can be of 3 types:
 Functional requirements
 Non-functional requirements
 Domain requirements
Functional Requirements: These are the requirements that the end user
specifically demands as basic facilities that the system should offer. It can be a
calculation, data manipulation, business process, user interaction, or any other
specific functionality which defines what function a system is likely to perform.
All these functionalities need to be necessarily incorporated into the system as
a part of the contract. These are represented or stated in the form of input to be
given to the system, the operation performed and the output expected. They are
basically the requirements stated by the user which one can see directly in the
final product, unlike the non-functional requirements. For example, in a hospital
management system, a doctor should be able to retrieve the information of his
patients. Each high-level functional requirement may involve several
interactions or dialogues between the system and the outside world. In order to

accurately describe the functional requirements, all scenarios must be
enumerated. There are many ways of expressing functional requirements e.g.,
natural language, a structured or formatted language with no rigorous syntax
and formal specification language with proper syntax. Functional Requirements
in Software Engineering are also called Functional Specification.
Non-functional requirements: These are basically the quality constraints that
the system must satisfy according to the project contract.Nonfunctional
requirements, not related to the system functionality, rather define how the
system should perform The priority or extent to which these factors are
implemented varies from one project to other. They are also called non-
behavioral requirements. They basically deal with issues like:
 Portability
 Security
 Maintainability
 Reliability
 Scalability
 Performance
 Reusability
 Flexibility
NFR’s are classified into following types:
 Interface constraints
 Performance constraints: response time, security, storage space, etc.
 Operating constraints
 Life cycle constraints: maintainability, portability, etc.
 Economic constraints
The process of specifying non-functional requirements requires the knowledge
of the functionality of the system, as well as the knowledge of the context within
which the system will operate.
They are divided into two main categories: Execution qualities like security and
usability, which are observable at run time. Evolution qualities like testability,
maintainability, extensibility, and scalability that embodied in the static structure
of the software system.
Domain requirements: Domain requirements are the requirements which are
characteristic of a particular category or domain of projects. Domain
requirements can be functional or nonfunctional. Domain requirements
engineering is a continuous process of proactively defining the requirements for
all foreseeable applications to be developed in the software product line. The
basic functions that a system of a specific domain must necessarily exhibit
come under this category. For instance, in an academic software that maintains
records of a school or college, the functionality of being able to access the list
of faculty and list of students of each grade is a domain requirement. These

requirements are therefore identified from that domain model and are not user
specific.
Other common classifications of software requirements can be:
1. User requirements: These requirements describe what the end-user wants
from the software system. User requirements are usually expressed in
natural language and are typically gathered through interviews, surveys, or
user feedback.
2. System requirements: These requirements specify the technical
characteristics of the software system, such as its architecture, hardware
requirements, software components, and interfaces. System requirements
are typically expressed in technical terms and are often used as a basis for
system design.
3. Business requirements: These requirements describe the business goals
and objectives that the software system is expected to achieve. Business
requirements are usually expressed in terms of revenue, market share,
customer satisfaction, or other business metrics.
4. Regulatory requirements: These requirements specify the legal or
regulatory standards that the software system must meet. Regulatory
requirements may include data privacy, security, accessibility, or other legal
compliance requirements.
5. Interface requirements: These requirements specify the interactions
between the software system and external systems or components, such as
databases, web services, or other software applications.
6. Design requirements: These requirements describe the technical design of
the software system. They include information about the software
architecture, data structures, algorithms, and other technical aspects of the
software.
By classifying software requirements, it becomes easier to manage, prioritize,
and document them effectively. It also helps ensure that all important aspects of
the system are considered during the development process.
Advantages of classifying software requirements include:
 Better organization
 Improved communication
 Increased quality.
 Improved traceability
Disadvantages of classifying software requirements include:
 Complexity
 Rigid structure
 Misclassification
REFINING THE USE CASES:

A use case diagram example consists of four use cases: place order, check status, fill
orders and establish credit. Order can be placed directly by customer or a salesperson
and they can also check the order status later on. Shipping clerk is responsible for filling
the order and the supervise can establish the credit level for customer according the
past record and financial information submitted by the customer. Now let us refine the
main use case – place order
Include Use Case - The include and extend relationships are drawn as dashed arrows
with the keyword «include» or «extend». The include relationship points at the use case
to be included; the extend relationship points at the use case to be extended.
Extend Use Case - A use case can also be deﬁned as an incremental extension to a base
use case. This is called an extend relationship. There may be several extensions of the
same base use case that may all be applied together.
Child Use Case - Use case generalization is drawn the same as any generalization, as a
line from the child use case to the parent use case with a large triangular arrowhead on
the parent end.
DEVELOPING THE SUPPLYMENTARY SPECIFICATION:
1. Objectives
The purpose of this document is to define requirements of the Wylie course registration (C-Registration)
system. This Supplementary Specification lists the requirements that are not readily captured in the use

cases of the use-case model. The Supplementary Specifications and the use-case model together capture a
complete set of requirements on the system.
2. Scope
This Supplementary Specification applies to the Wylie course registration system which will be developed
by the Wylie College Information Systems (IT) department. The IT department will develop this client-
server system to interface with the existing course catalog database.
The C-Registration System will enable students to register for courses on-line. The C-Registration System
allows professors to select their teaching courses and to maintain student grades.
This specification defines the non-functional requirements of the system; such as reliability, usability,
performance, and supportability as well as functional requirements that are common across a number of use
cases. (The functional requirements are defined in the Use Case Specifications.)
3. References
Applicable references are:
1. System Business Case for the C-Registration System, WyIT388, DRAFT, 1998, Wylie College IT.
2. Course Billing Interface Specification, WC93332, 1985, Wylie College Press.
3. Course Catalog Database Specification, WC93422, 1985, Wylie College Press.
4. Stakeholder Requests Document for the C-Registration System, WyIT389, V1.0, 1998, Wylie College IT.
5. Vision Document of the C-Registration System, WyIT387, V1.0, 1998, Wylie College IT.
6. Glossary for the C-Registration System, WyIT406, V2.0, 1999, Wylie College IT.
7. Use Case Spec - Close Registration, WyIT403, V2.0, 1999, Wylie College IT.
8. Use Case Spec – Login, WyIT401, V2.0, 1999, Wylie College IT.
9. Use Case Spec - Maintain Professor Info, WyIT407, Version 2.0, 1999, Wylie College IT.
10. Use Case Spec - Register for Courses, WyIT402, Version 2.0, 1999, Wylie College IT.
11. Use Case Spec - Select Courses to Teach, WyIT405, Version 2.0, 1999, Wylie College IT.
12. Use Case Spec - Maintain Student Info, WyIT408, Version 2.0, 1999, Wylie College IT.
13. Use Case Spec - Submit Grades, WyIT409, Version 2.0, 1999, Wylie College IT.
14. Use Case Spec - View Report Card, WyIT410, Version 2.0, 1999, Wylie College IT.
1. Functionality
This section lists functional requirements that are common to more than one use case.
1. System Error Logging
All system errors shall be logged. Fatal system errors shall result in an orderly shutdown of the
system.
The system error messages shall include a text description of the error, the operating system error
code (if applicable), the module detecting the error condition, a data stamp, and a time stamp. All
system errors shall be retained in the Error Log Database.
2. Remote Access

All functionality shall be available remotely through an internet connection. This may require applications
or controllers running on the remote computers.
2. Usability
This section lists all of those requirements that relate to, or affect, the usability of the system.
1. Windows Compliance
The desktop user-interface shall be Windows 95/98 compliant.
2. Design for Ease-of-Use
The user interface of the C-Registration System shall be designed for ease-of-use and shall be
appropriate for a computer-literate user community with no additional training on the System.
3. Online Help
Each feature of the C-Registration System shall have built-in online help for the user. Online Help shall
include step by step instructions on using the System. Online Help shall include definitions for terms and
acronymns.
3. Reliability
This section lists all reliability requirements.
1. Availability
The C-Registration System shall be available 24 hours a day, 7 days a week. There shall be no
more than 4% down time.
2. Mean Time Between Failures
Mean Time Between Failures shall exceed 300 hours.
4. Performance
The performance characteristics of the system are outlined in this section.
1. Simultaneous Users
The system shall support up to 2000 simultaneous users against the central database at any given
time, and up to 500 simultaneous users against the local servers at any one time.
2. Database Access Response Time
The system shall provide access to the legacy course catalog database with no more than a 10
second latency.

3. Transaction Response Time
The system must be able to complete 80% of all transactions within 2 minutes.
5. Supportability
This section defines any requirements that will enhance the supportability or maintainability of the system
being built.
1. New Releases Downloadable
Upgrades to the PC client portion of C-Registration shall be downloadable from the UNIX Server over the
internet. This feature enables students to have easy access to system upgrades.
6. Design Constraints
This section lists any design constraints on the system being built.
1. Course Catalog Legacy System
The system shall integrate with existing legacy system (course catalog database) which operates
on the College DEC VAX Main Frame.
2. Billing System
The C-Registration System shall interface with the existing Course Billing System which operates
on the College DEC VAX Main Frame.
3. Platform Requirements
The client portion of the C-Registration System shall operate on any personal computer with a 486
processor or greater. The client portion shall require less than 20 MB disk space and 32 MB RAM.
The server portion of the C-Registration System shall operate on the Wylie College UNIX server.
4. Internet Browsers
The web-based interface for the C-Registration System shall run in Netscape 4.0.4 and Internet
Explorer 4.0 browsers.
5. Java Compatibility
The web-based interface shall be compatible with the Java 1.1 VM runtime environment.
AMBIGUTIY:
Ambiguity and lack of specification in software engineering can lead to
misunderstanding, errors, and project delays. To address these issues, it's important to

follow a structured approach to clarify requirements and reduce ambiguity. Here are the
steps to achieve this:
1. Requirement Elicitation:
 Start by gathering requirements from stakeholders, such as clients, end-users,
and project managers.
 Use various techniques like interviews, surveys, workshops, and brainstorming
sessions to collect information.
2. Documentation:
 Document the gathered requirements in a clear and structured manner.
 Use plain language and avoid technical jargon or ambiguous terms.
 Include diagrams, flowcharts, and mockups to help visualize requirements.
3. Validation:
 Review the initial documentation with stakeholders to ensure that it accurately
represents their needs and expectations.
 Validate requirements for feasibility, consistency, and completeness.
4. Prioritization:
 Prioritize requirements based on their importance and impact on the project's
success.
 Use techniques like MoSCoW (Must have, Should have, Could have, Won't have)
to categorize requirements.
5. Prototyping:
 Create prototypes or mockups of the software to provide stakeholders with a
visual representation of how the system will work.
 Prototypes can help identify misunderstandings and ambiguities early in the
process.
6. Specification Documents:
 Develop detailed specification documents that provide a clear, unambiguous
description of each requirement.
 Use a consistent format, such as User Stories, Use Cases, or Functional
Specifications.
7. Review and Feedback:
 Conduct regular reviews of the specification documents with stakeholders,
including developers, testers, and users.
 Encourage feedback and clarification requests.
8. Traceability:
 Establish traceability between requirements and other project artifacts, such as
test cases and code modules.
 This ensures that each requirement is addressed and tested.
9. Change Management:

 Implement a change control process to manage and document any changes to
the requirements.
 Assess the impact of changes on the project schedule and budget.
10. Formalizing Acceptance Criteria:
 For each requirement, define clear acceptance criteria that specify when a
requirement is considered met.
 This helps in objectively verifying that the software meets the specified
requirements.
11. Continuous Communication:
 Maintain open and continuous communication with stakeholders throughout the
project's lifecycle to address any emerging ambiguities or changing
requirements.
12. Quality Assurance:
 Implement quality assurance processes to ensure that the software meets the
specified requirements and is free of defects.
13. Testing:
 Develop test cases based on the specification documents and acceptance criteria
to verify that the software functions correctly.
14. Documentation Updates:
 Keep the specification documents up-to-date as the project progresses and
changes are made.
15. Training and Knowledge Sharing:
 Ensure that all team members and stakeholders have a clear understanding of the
requirements through training and knowledge sharing sessions.
16. Feedback Loop:
 Establish a feedback loop to gather post-implementation feedback from users to
identify any unmet or misunderstood requirements.
By following these steps, you can reduce ambiguity, improve specification, and enhance
the overall quality of the software development process, leading to successful project
outcomes.
Specification:
Specification in software engineering refers to the process of defining and documenting
the detailed requirements, behaviors, and characteristics of a software system. It plays a
crucial role in the software development lifecycle as it serves as a blueprint for what the
software is supposed to do and how it should behave. A well-defined specification helps
ensure that the software meets the needs and expectations of stakeholders, including

clients, users, and development teams. Here are key aspects and components of
software specification:
1. Functional Requirements: These specify what the software is supposed to do. They
describe the system's functions, features, and interactions with users or other systems.
Functional requirements often include use cases, user stories, and detailed descriptions
of system behavior.
2. Non-functional Requirements: Also known as quality attributes or system qualities,
these specify the characteristics the software must have, such as performance,
scalability, reliability, security, and usability. Non-functional requirements provide
constraints and criteria that the system must meet.
3. Use Cases: Use cases describe interactions between users and the system. They typically
consist of scenarios that illustrate how the system responds to specific actions or events
initiated by users or external systems.
4. User Stories: User stories are concise, informal descriptions of system features or
functionality from the perspective of an end user. They are often used in Agile
methodologies and help prioritize and communicate user needs.
5. Functional Specifications: These are detailed documents that describe the behavior of
the software in a precise and unambiguous manner. They often include flowcharts, state
diagrams, and pseudocode to illustrate the expected system behavior.
6. System Architecture: Specification may also include an architectural overview, which
describes the high-level structure of the software, including components, modules, and
their interactions.
7. Data Model: Specifications often include data models that define the structure and
relationships of data entities within the system, such as databases or data flows.
8. Interfaces: Specifications detail the interfaces between various components of the
system, including external systems, APIs, and user interfaces. Interface specifications
describe how data and control flow between these components.
9. Acceptance Criteria: For each requirement or user story, clear acceptance criteria are
defined. These criteria specify conditions under which a requirement is considered
satisfied, helping to objectively validate the software's functionality.
10. Constraints and Assumptions: Any constraints or assumptions made during the
specification process are documented. Constraints may include limitations on
technology choices or budget constraints, while assumptions address factors that may
impact the project.
11. Traceability: Traceability matrices are used to establish links between requirements, test
cases, and other project artifacts. This ensures that every requirement is addressed and
tested.
12. Change Control: A process for managing changes to the specification is established to
handle evolving requirements and minimize scope creep.

13. Documentation Standards: Specification documents should adhere to clear
documentation standards and templates to ensure consistency and readability.
Effective software specification is critical to avoid misunderstandings, reduce ambiguity,
and provide a clear roadmap for developers and testers. It serves as a foundation for
software design, implementation, testing, and validation, ultimately leading to the
successful delivery of a software project that meets stakeholder expectations.
TECHNICAL METHODS FOR SPECIFYING REQUIREMENTS:
Specifying requirements is a critical phase in software engineering, as it sets the
foundation for the entire development process. There are several technical methods and
techniques available for specifying requirements, and the choice of method often
depends on the project's complexity, stakeholders, and specific needs. Here are some
common technical methods for specifying requirements in software engineering:
1. Natural Language: Natural language requirements are written in plain, everyday
language. While this method is easy to understand, it can be ambiguous and open to
interpretation. To mitigate this, structured templates and guidelines can be used to
improve clarity.
2. Structured English: This method uses a formalized subset of the English language to
specify requirements. It employs standardized sentence structures and keywords to
describe system behavior.
3. Use Cases: Use cases describe interactions between the system and its users or other
systems. They often include scenarios, actors, and detailed descriptions of specific
interactions to capture system functionality and behavior.
4. User Stories: Popular in Agile methodologies, user stories are short, informal
descriptions of a feature or functionality from the perspective of an end-user. They are

concise and typically follow a format like "As a [user role], I want [an action] so that [a
benefit]."
5. Entity-Relationship Diagrams (ERDs): ERDs are used to model data and their
relationships within a system. They help specify requirements related to data storage
and retrieval.
6. Data Flow Diagrams (DFDs): DFDs visualize how data flows through a system,
including processes that manipulate the data. They are useful for specifying data-related
requirements and system behavior.

7. State Transition Diagrams: These diagrams model the different states a system or an
object can be in and transitions between them. They are particularly useful for specifying
requirements related to system states and event-driven behavior.
8. Structured Analysis and Design Technique (SADT): SADT uses graphical symbols and
diagrams to represent system processes, data flows, and entities. It can be helpful for
specifying requirements and understanding system structure.
9. Formal Methods: These are mathematical techniques used to specify requirements
precisely. Methods like Z, B, and Alloy use formal logic and notation to describe system
behavior and properties. They are often used in safety-critical and mission-critical
systems.
10. Unified Modeling Language (UML): UML is a standardized modeling language that
includes various diagram types, such as use case diagrams, class diagrams, and
sequence diagrams. It can be used to specify both functional and structural
requirements.
11. Requirements Specification Documents: Creating comprehensive requirement
documents is another approach. These documents may include a combination of textual
descriptions, diagrams, and other visuals to communicate requirements effectively.
12. Prototyping: In some cases, creating a prototype of the software can be a useful way to
specify requirements. Prototypes provide a tangible representation of the system,
helping stakeholders better understand and refine their requirements.

13. User Interface (UI) Mockups: For systems with significant user interfaces, UI mockups
and wireframes can be used to specify requirements related to the visual and interactive
aspects of the software.
14. Traceability Matrices: These matrices link requirements to design elements, test cases,
and other project artifacts, ensuring that each requirement is addressed and tested.
Selecting the most appropriate method or combination of methods depends on the
specific project and its unique requirements. Often, a combination of these methods is
used to comprehensively specify software requirements, taking into account different
aspects of the system.

UNIT 4 REFINING THE SYSTEM DEFINITION.docx

Recommended

More Related Content

Similar to UNIT 4 REFINING THE SYSTEM DEFINITION.docx (20)

Recently uploaded (20)

UNIT 4 REFINING THE SYSTEM DEFINITION.docx