Unit 2
Requirements Engineering & Analysis
User requirements
Describe what the user does in the device, also referred to as user needs, such as what tasks that users must be able to perform. In a User Requirements Document (URD) using narrative text, user requirements are normally reported. In general, user specifications are signed off by the user and used as the key input to build device requirements.
In designing a software product, a significant and challenging step is to decide what the consumer really wants it to do. This is because the consumer is frequently unable to express their needs and desires in their entirety, and the data they provide can also be incomplete, unreliable and self-conflicting. The burden of thoroughly knowing what the client needs falls on the business analyst. This is why user demands are normally taken into account separately from device specifications.
The business analyst carefully analyses user requirements and carefully builds and records a set of high-quality system requirements to ensure that these quality characteristics are met by the requirements.
Fig 1: User and system requirements
System requirements
The building blocks developers use to build the system are system specifications. These are the standard "shall" statements that define what the "shall do. System requirements of the system are categorized as either functional or additional requirements."
For instance, the entry and printing of cost estimates will involve a system; this is a practical requirement. All the remaining specifications not covered by the functional requirements are specified by supplementary or non-functional requirements. Instead of non-functional specifications, I prefer to use the word supplementary demands; who wants to be labelled non-functional? Supplementary specifications are often called requirements for service quality.
In the system design, the strategy for implementing functional specifications is comprehensive. In the system architecture, the plan for implementing supplementary specifications is comprehensive.
The following list indicates different kinds of supplementary specifications:
● Accessibility
● Accuracy
● Audit, control, and reporting
● Availability
● Backup and restore
● Capacity, current and forecast
● Certification
● Compliance
● Compatibility of software, tools, standards, platform, database, and the like
● Concurrency
● Configuration management
● Dependency on other parties
● Deployment
● Documentation
● Disaster recovery
Key takeaways
- In a User Requirements Document (URD) using narrative text, user requirements are normally reported.
- System requirements of the system are categorized as either functional or additional requirements."
2.2.1 Functional Requirements
A functional requirement in software engineering determines a device or component. It defines the functions that must be performed by a programme. Nothing but inputs, their actions, and outputs are a function. It can be a calculation, data manipulation, business method, user interaction, or some other particular feature that determines what is likely to perform a system's purpose.
Requirements for usable applications allow you to capture the system's expected actions. This conduct may be represented in the form of functions, facilities or tasks or which system must be executed.
Example of functional requirements:
Some examples of non-functional specifications are available here:
● Only workers at the managerial level have the right to access revenue data.
● It is important to integrate the software framework with the banking API.
● Automatically, the programme validates clients against the ABC Contact Management System
● The Sales System should allow users to record sales of customers
Advantages of functional requirements
❏ Helps you to check if all the functionalities specified in the functional requirement of that application are given by the application.
❏ A document of functional specifications allows you to identify a system's functionality or one of its subsystems.
❏ Functional specifications help to define missing requirements along with requirement review. They help describe the intended service and behaviour of the system clearly.
❏ Errors caught in the collection stage of the Practical Requirement are the cheapest to repair.
2.2.2 Non - Functional Requirements
The quality attribute of a software system is specified by a non-functional requirement. They reflect a collection of criteria that are used to judge a system's basic activity. How quick, for example, does the website load?
To ensure the usability and efficacy of the entire software framework, a non-functional requirement is vital. Failure to meet non-functional specifications will lead to systems that do not meet the needs of users.
Non-functional specifications allow you to enforce system design restrictions or limitations through the various agile backlogs. For e.g., if the number of simultaneous users is > 10000, the site should be loaded within 3 seconds. It is just as important as a functional requirement to define non-functional requirements.
Example of non - functional requirements:
Some examples of non-functional specifications are available here:
● Users must, immediately after the first successful login, adjust the initially assigned login password. In addition, the original can never be reused.
● Any failed attempt by a user to access a data item must be registered on the audit trail.
● A website should be able to manage the effect of 20 million users on its results.
● The device needs to be portable. Therefore, switching from one OS to another OS causes no problem.
Advantages of non - functional requirements
Non-functional testing's benefits/pros are:
❏ The non-functional specifications ensure that legal and regulatory laws are observed by the software system.
❏ They guarantee the reliability, usability and productivity of the software system.
❏ They guarantee good user experience and ease of software activity.
❏ They help to formulate the information system security strategy,
Key takeaways
- A functional requirement in software engineering determines a device or component.
- It defines the functions that must be performed by a programme.
- The quality attribute of a software system is specified by a non-functional requirement.
Fig 2: Non - functional requirement
Requirement engineering is the broad spectrum (variety, range) of tasks and techniques that lead to an understanding of requirements.
In other words, RE (requirement engineering) refers to the mechanism in which specifications are specified, recorded and preserved.
A major software engineering operation is from a requirement engineering that starts during the communication activity and continues into the modelling activity. It needs to be customized to the requirements of the process, the project, the product and the people doing the job.
Software Requirements are a set of conditions or a capability possessed by software or system components to solve a real-world problem. The problems can be to automate a part of a system to correct shortcomings of an existing system, to control
a device, and so on. IEEE defines a requirement as:
“A condition or capability needed by a user to solve a problem or achieve an objective” or “The capability possessed by a system to satisfy a contract, standard, specification, or other formally imposed documents”.
When users request for software, they possess an approximation of what the new system should be capable of doing. Requirements differ from one user to another user and from one business process to another business process. Reliability means Operational reliability.
It is described as the ability of a system or component to perform its required functions under static conditions for a specific period. It can also be described as the probability that a software system fulfils its assigned task in a given environment for a predefined number of input cases, assuming that the hardware and the input are free of error.
Software can be defined as a collection of programs, documentation and operating procedures. Institute of Electrical and Electronic Engineers (IEEE) defines software as “a collection of computer programs, procedures, rules, and associated documentation and data”.
It contains seven different activities -
❏ Inception
❏ Elicitation
❏ Elaboration
❏ Negotiation
❏ Specification
❏ Validation
❏ Management
2.3.1 Elicitation
It is linked to the different ways used to obtain information and specifications about the project domain. Customers, company manuals, current applications of the same kind, specifications and other project stakeholders are among the different sources of domain information.
The methods used for the elicitation of requirements include interviews, brainstorming, mission analysis, Delphi technology, prototyping, etc. Elicitation does not generate formal models of the known specifications. Instead, it expands the analyst's domain expertise and thus helps to provide insight into the next step.
2.3.2 Specification
This practise is used to develop structured models of software requirements. All specifications, including both functional and non-functional requirements and limitations, are defined in their entirety by these models. More information about the issue may be needed during the specification, which can again activate the elicitation phase.
ER diagrams, data flow diagrams (DFDs), feature decomposition diagrams (FDDs), data dictionaries, etc. are the models used at this point.
2.3.3 Validation
It refers to a different set of tasks which ensure that customer requirements are traceable to the software that has been installed.
If specifications are not checked, errors will spread to the successive stages in the requirement descriptions, resulting in a lot of adjustment and rework.
For this method, the key steps include:
● The specifications should be compatible with all the other specifications, i.e. no two specifications should clash with each other.
● In every way, the specifications should be complete.
● The parameters should be technically feasible.
2.3.4 Negotiation
In the negotiating task, a software engineer decides how scarce business resources can accomplish the mission.
To build rough production guesses and access to the effect of the requirement on the cost and delivery time of the project.
The goal of this negotiation is to create a project plan that meets the needs of stakeholders while representing the real-world constraints that have been imposed on the software team (e.g. Time, personnel, budget).
The best deals pursue a "win-win" outcome. That is, by having the method or product that meets most of their needs, stakeholders win and you win by working towards practical and achievable budgets and deadlines.
Boehm [Boe98] defines a set of negotiation activities at the beginning of each software process iteration.
Key takeaways
- Requirement engineering is the broad spectrum (variety, range) of tasks and techniques that lead to an understanding of requirements.
- RE (requirement engineering) refers to the mechanism in which specifications are specified, recorded and preserved.
- Requirements differ from one user to another user and from one business process to another business process.
As a function of customer satisfaction, Kano analysis helps one to prioritize requirements. Kano specified four categories into which it is possible to classify each function or necessity.
- Surprise and delight
Capabilities that distinguish a service from its competition (e.g. the nav-wheel on an iPod)
2. More is better
Dimensions with a simple path of increasing utility along a continuum (e.g. Battery life or song capacity)
3. Must be
Functional barriers to entry: consumers would not use the product without these capabilities (e.g. UL approval)
4. Better not be
Represents material that dissatisfies clients (e.g. Inability to increase song capacity via upgrades).
Surprise and delight requirement:
Think of software as a customer for just a moment, not an accountant. We want software that is interesting to use and enjoyable. User interface affordances that allow us to just "do what comes naturally" and make the programme do precisely what we want. Fresh innovations that render better apps. When we click it, we're not talking about a button that brings up dancing squirrels, we're talking about useful features that make great apps.
These may be the criteria behind the delightful characteristics described above.
● When holding the iPod in one hand, users must be able to pick songs.
● With the expectation that users would never delete emails, the system must have an easy way to organize emails.
● The framework offers appropriate support information for the context in which the consumer seeks assistance.
More is better requirement:
These are the terms that are most readily understood: bigger, quicker, better, stronger. The difficulty in writing a better requirement is to know when sufficient is enough. "They would be ambiguous requirements if we were to write requirements that said "minimize" or "maximize. It would be entirely impractical if we were to unambiguously request that our developers minimize search time.
It can also be very difficult to define accurate targets. The decreasing returns law comes into play. In economics, there is a term called utility that reflects the tangible and intangible benefits of something. With respect to the target users, we may consider the usefulness of a function.
A graph of the search-result generation speed utility will look like the following:
Fig 3: Graph of search result
We can see that the associated gain to the consumer of further changes in speed is decreased as the speed of results increases. To define the criterion, we have only defined the benefit side of the cost-benefit analysis required. We now have an idea of the cost of implementing search after getting feedback from our implementation team, as seen in the following graph.
Fig 4: Graph of cost and result
As we see, making increasingly smaller speed changes is progressively becoming more costly. We need to find the point in the curves where the incremental advantage of searching faster is equivalent to the incremental expense of searching faster to decide the ideal specification.
As shown in the next figure, we can do that by graphing utility versus cost.
Fig 5: Graphing utility cost
The circle displays the point where the curve's slope is equal to 1. An additional increase in speed offers less value at this point in the curve than the associated increase in cost.
Must be requirements
These are the criteria that when they talk about requirements, most people think about. These are the best specifications to evoke.
Stakeholders will typically tell us what the app needs them to have. Am I hot in our world or not? We see that 37 signals rely on this as their primary criteria for inclusion in an initial software release after prioritization of requirements. They prefer to place only critical specifications or 'must be' in the initial software update.
Better not to be requirement
No, this is just the opposite of surprise and delight. Then critics complain about what holds it back if dreamers think about what makes something great. In Kano's analysis, we don't think this bucket really has a place. "Saying "Users don't like complicated navigation" offers no advantage over saying "Users prefer intuitive navigation. We recommend that this category not be used at all.
Key takeaways
- As a function of customer satisfaction, Kano analysis helps one to prioritize requirements.
- Kano specified four categories into which it is possible to classify each function or necessity.
In the Requirement Traceability Matrix or RTM, we set up a process to record the relations between the client's suggested user specifications and the system being designed. In short, it is a high-level document that maps and traces user specifications with test cases to ensure that appropriate testing levels are accomplished with each and every requirement.
The method for evaluating all test cases specified for each requirement is called Traceability. Traceability helps us to assess which specifications have produced the most defects during the phase of testing.
Full test coverage is and should be the focus of every research interaction. It literally means, by coverage, that we need to test anything that needs to be tested. 100 percent test coverage should be the goal of every research project.
Requirements the Traceability Matrix offers a way to ensure that the coverage element is tested. It helps to define coverage gaps by providing a snapshot. In short, it can also be referred to as metrics that specify for each requirement the number of test cases run, passed, failed or blocked, etc.
Types of Traceability Matrix
Forward Traceability:
Requirements for test cases of 'Forward Traceability'. It guarantees that the project is moving according to the desired path and that every condition is thoroughly tested.
Fig 6: forward traceability
Backward Traceability:
With the 'Backward Traceability' criteria, the test cases are mapped. Its primary objective is to ensure that the new product being produced is on the right track. It also helps to decide that no additional undefined features are implemented and the project's scope is therefore affected.
Fig 7: backward traceability
Bi-Directional Traceability:
(Forward + Backward): A Strong Traceability matrix contains references to criteria from test cases and vice versa (requirements to test cases). This is referred to as Traceability 'Bi-Directional.'
Fig 8: Bi - directional traceability
Key takeaways
- The method for evaluating all test cases specified for each requirement is called Traceability.
- Traceability helps us to assess which specifications have produced the most defects during the phase of testing.
- Requirements the Traceability Matrix offers a way to ensure that the coverage element is tested.
- It helps to define coverage gaps by providing a snapshot.
A specification of software requirements (SRS) is a document that explains what the software is supposed to do and how it is expected to work. It also describes the functionality needed by the product to fulfil the needs of all stakeholders (business, users).
A standard SRS consists of -
● A purpose - Initially, the main objective is to clarify and illustrate why this document is important and what the intention of the document is.
● An overall description - The product summary is explained here. It's simply a rundown or an overall product analysis.
● Scope of this document - This outlines and demonstrates the overall work and primary goal of the paper and what value it can bring to the consumer. It also provides a summary of the cost of construction and the necessary time.
When embedded in hardware, or when linked to other software, the best SRS documents describe how the software can communicate.
Why we use SRS document -
For your entire project, a software specification is the foundation. It sets the structure that will be followed by any team involved in development.
It is used to provide multiple teams with essential information - creation, quality assurance, operations, and maintenance. This keeps it on the same page for everybody.
The use of the SRS helps ensure fulfilment of specifications. And it can also help you make decisions about the lifecycle of your product, such as when to remove a feature.
Writing an SRS can also reduce time and costs for overall production. The use of an SRS especially benefits embedded development teams.
Key takeaways
- SRS is a document that explains what the software is supposed to do and how it is expected to work.
- For your entire project, a software specification is the foundation.
- The use of the SRS helps ensure fulfilment of specifications.
The process to gather the software requirements from client, analyze and document
Them is known as requirement engineering main goal of requirement engineering is
To develop and maintain sophisticated and descriptive ‘System Requirements
Specification’ document.
Requirement Engineering Process includes four steps:
a) Feasibility Study
b) Software Requirement Specification
c) Requirement Gathering
d) Software Requirement Validation
Fig 9: software requirement process
a) Feasibility study
When the client approaches the organization for getting the desired product developed, it comes up with rough idea about what all functions the software must perform and which all features are expected from the software. Referencing to this information, the analysts does a detailed study about whether the desired system and its functionality are feasible to develop.
This feasibility study is focused towards the goal of the organization. This study analyses whether the software product can be practically materialized in terms of implementation, contribution of project to organization, cost constraints and as per values and objectives of the organization. It explores technical aspects of the project
And products such as usability, maintainability, and productivity and integration ability.
The output of this phase should be a feasibility study report that should contain adequate comments and recommendations for management about whether or not the project should be undertaken.
b) Software Requirement Specification-
SRS is a document created by system analyst after the requirements are collected from various stakeholders. It defines how the intended software will interact with hardware, external interfaces, speed of operation, response time of system, portability of software across various platforms, maintainability, speed of recovery after crashing, Security, Quality, Limitations etc.
The requirements received from clients are written in natural language. It is the responsibility of the system analyst to document the requirements in technical language so that they can be comprehended and useful by the software development team.
c) Requirement Gathering
If the feasibility report is positive towards undertaking the project, next phase starts with gathering requirements from the user. Analysts and engineers communicate with the client and end-users to know their ideas on what the software should provide and which features they want the software to include.
d) Software Requirement Validation
After requirement specifications are developed, the requirements mentioned in these documents are validated. User might ask for illegal, impractical solution or experts may interpret the requirements incorrectly. This results in huge increase in cost if not
Nipped in the bud.
Requirements can be checked against following conditions -
o Able to be practically implemented
o Should be valid and as per functionality and domain of software
o No ambiguities
o Must be complete
o Should be clearly demonstrated
Key takeaways
- The process to gather the software requirements from clients, analyze and document them is known as requirement engineering.
- The main goal of requirement engineering is to develop and maintain sophisticated and descriptive ‘System Requirements Specification’ documents.
It is necessary to write an SRS text. It's not always easy to do, though.
To write an effective SRS text, here are five measures you can follow.
- Create an outline (or use an SRS template)
Your first move is to build an outline specification for your programme specifications. This could be something that you yourself make. Or you can use an existing prototype with SRS.
Here's what your outline could look like if you're making this yourself:
1. Introduction
1. 1 Purpose
1. 2 Intended Audience
1. 3 Intended Use
1. 4 Scope
1.5 Definitions and Acronyms
2. Overall Description
2. 1 User Needs
2. 2 Assumptions and Dependencies
3. System Features and Requirements
3. 1 Functional Requirements
3. 2 External Interface Requirements
3. 3 System Features
3. 4 Nonfunctional Requirements
You're able to start filling it out once you have your clear outline.
2. Start with a purpose
There is a very significant introduction to your SRS. This sets the target for the product you're creating.
So, start by defining your product's function.
Intended Audience and Intended Use
Define who will have access to the SRS in your company, and how they should use it. Developers, reviewers and project managers can be part of this. It may also include stakeholders, including leadership teams, distribution, and marketing in other departments.
Product scope
Describe the programme that is being defined. And they have advantages, priorities, and objectives. This should relate to overall business objectives, especially if the SRS will be accessed by teams outside of growth.
Definition and Acronyms
Including a risk concept is wise. For many developers, especially those working on security-critical development teams, avoiding risk is top-of-mind.
3. Give an overview of what you’ll build
Your next move is to include a summary of what you will be constructing. Is it a product upgrade to an existing one? Is this an add-on to a product that you have already developed?
These are crucial to explain in advance, so everyone understands what you're creating.
You can also clarify why you are constructing it and who it is for.
User needs
User specifications, or user classes and features, are important. You'll need to define who and how the product will be used.
You'll have primary and secondary users who will frequently use the product. The needs of a separate buyer of the item (who may not be a primary/secondary user) may also need to be specified. And, if you're designing a medical device, for instance, you'll need to explain the needs of the patient.
Assumption and dependencies
There may be variables influencing the ability to meet the criteria specified in your SRS. What factors are those?
Are there any assumptions you're making that could turn out to be wrong with the SRS? You should have, as well, those here.
Finally, you should remember whether any external factors are depending on your project. This may involve software components from another project that you are reusing.
4. Detail your specific requirement
For your development team, the next section is key. This is where the basic specifications for the construction of your product are detailed.
Functional requirement
To build your product, functional specifications are crucial.
These specifications may include an infusion and a battery if you are developing a medical device. And you may have a subset of risks and requirements under these functional requirements.
External interface requirement
External specifications for interfaces are types of functional requirements. For embedded systems, they're essential. And they outline how other components can interact with your product.
There are many types of interfaces for which you may have specifications, including:
● User
● Hardware
● Software
● Communications
System features
System characteristics are functional requirement types. In order for a system to operate, these are features that are needed.
Other non- functional requirements
Non-functional criteria may be just as relevant as those that are functional.
These include, among others:
● Performance
● Safety
● Security
● Quality
Depending on your business, the significance of this form of requirement can vary. Safety standards in the medical device industry, for instance, would be crucial.
5. Get approval of an SRS
You'll need to have it approved by key stakeholders once you've completed the SRS. And the current edition of the document should be checked by all.
Key takeaways
To write an effective SRS text, there are five measures you should follow.
- Introduction
1. Purpose
This document is intended to delineate OSS features in order to serve, on the one hand, as a guide for developers and, on the other, as a software validation document for the prospective customer.
The Online Shopping System (OSS) for the web application of electronic item shops is intended to provide vendors as well as customers with complete solutions through a single way of using the internet.
1. Scopes
This system allows the customer to keep their cart online to add or remove the items.
1. Definitions
OSS- Online system for shopping (for electronics item shop)
SRS- Specification for Software Requirement
GUI- User Graphical Interface
Stakeholder- The person who is interested in the scheme
Ex. - Clients, managers, tourists, etc.
1. Overview
This system provides clients with a simple solution for buying
Without going to the store and even to the shop owner, the product
For the commodity to be sold.
This proposed system can be used by any naïve user and does not require any degree of education, experience or technological skill in the field of computers, but it will be of good benefit if the user has the right knowledge of how to operate a computer.
2. Overall description
The application for the Online Shopping System (OSS) allows suppliers to set up online shops, customers to search through shops, and a system administrator to accept and deny new shop requests and manage shop category lists. The developer is also developing an online shopping site to handle the goods in the store and also help consumers to buy them online without physically visiting the store.
1. Product perspective
This item targeted a person who may not want to visit the store because he does not have time for it or may not be interested in going there and dealing with a lot of formalities.
2. Product functions
This case for use should be provided by OSS:
Fig 10: Online shopping system
3. User characteristics
Users should be familiar with words such as login, register, system of order, etc.
4. Principle actors
Principle Actors are Customer and Administrator.
5. General constraints
For OSS, a complete internet connection is needed.
OSS operations involve an Internet connection.
3. Specific requirement
1 functional requirements
This segment gives a description of the system's specifications.
Various functional modules that the device will incorporate would be -
● Description
● Registration
● Login
● Changes to cart
● Payment
● Logout
2 non - functional requirements
There will be Non-Functional Specifications following in the Internet insurance:
● 24X7 availability.
● Safe access to sensitive data from customers.
● Better design of components to achieve better peak-time performance.
3 performance requirements
To sustain an appropriate speed at the full number of speeds Uploads from a specific customer as any number of users are allowed. It is possible to access the device at any time.
3.4 technical issue
The client-server architecture can operate with this framework. The internet will be needed. A server that will be able to run the PHP software.
4. Interface requirement
There may be various product interfaces:
● Login Page
● Registration Form
● There will be a screen showing details that the shop has about the items.
● If customers click the purchase button, another shopping cart screen will appear.
● The system will submit a copy of the bill to the customer's email address after purchasing the items.
5. System design specification
1 architectural design
It is a way to graphically reflect device requirements; this has led to modular design. A DFD represents a data flow (logical) rather than how it is.
They do not depend on software, hardware, data structure or organisation of files. It is also known as the 'bubble kind'.
A DFD is a formal analysis and design instrument that can be used in place of, or in combination with, information-oriented and process-oriented system flowcharts for flowcharting.
A DFD is known as an abstract of the logic of a system flowchart that is data-oriented or process-oriented.
Fig 11: Context analysis diagram (CAD)
Fig 12: 1 level DFD for admin
Fig 13: 1 level for DFD customer
Requirements Analysis
Analysis of requirements is an important and necessary task after elicitation. To render clear and unambiguous demands, we evaluate, refine, and scrutinize the collected specifications. All specifications are checked by this operation which can include a graphical view of the entire system. It is expected that the understandability of the project will substantially increase after the completion of the study.
Here, the dialogue with the client may also be used to illustrate points of misunderstanding and to understand which specifications are more relevant than others.
The different steps in the study of requirements are shown in Fig:
Fig 14: Steps of requirements analysis
- Draw the context diagram:
A basic model describing the boundaries and interfaces of the proposed structures with the external world is the context diagram. This describes the entities that communicate with the system outside the proposed system.
The context diagram of the student outcome management system is given below.
Fig 15: Context diagram for student management
II. Development of a Prototype (optional):
Constructing a prototype, something that looks and ideally works as part of the device they claim they want, is one successful way to find out what the consumer needs.
Until the user is consistently pleased, we will use their input to change the prototype. The prototype therefore allows the customer to imagine the device proposed and increase the understanding of requirements.
A prototype may help both parties to make a final decision if developers and users are not sure about some of the elements.
The prototype could be designed at a reasonably low cost and quickly. Therefore, in the final framework, it would still have drawbacks and would not be reasonable. This task is optional.
III. Model the requirements:
Typically, this method consists of different graphical representations of the functions, data entities, external entities, and their relationships. It will help to find wrong, contradictory, incomplete, and superfluous criteria in the graphical view. The Data Flow diagram, Entity-Relationship diagram, Data Dictionaries, State-transition diagrams, etc., contain such models.
IV. Finalize the requirements:
We will have a clearer understanding of the behaviour of the system after modelling the requirements. It has established and corrected the contradictions and ambiguities. The flow of information among different modules has been analyzed. The practices of elicitation and interpretation have provided greater insight into the scheme. The assessed requirements are now finalized, and the next step is to record these requirements in a specified format.
Key takeaways
- Analysis of requirements is an important and necessary task after elicitation.
- All specifications are checked by this operation which can include a graphical view of the entire system.
For a computer-based system, there are several different ways of looking at the specifications. Different representation types compel you to consider criteria from multiple points of view, an approach that is more likely to expose omissions, contradictions, and uncertainty.
2.11.1 Scenario Based Modeling
From the user's perspective, the system is represented using a Scenario-based methodology. Basic use cases and their accompanying use-case diagrams, for instance, develop into more elaborate use cases based on models.
The first component of the model that is developed is mostly scenario-based elements of the requirements model. Three stages of elaboration are shown, resulting in a representation based on scenarios.
Fig 16: Activity diagram for Eliciting
2.11.2 Class Based modeling
Each scenario of use involves a selection of artefacts that are manipulated as an actor communicates with the device. Such artefacts are grouped into groups, a group of items with similar characteristics and common behaviours.
Fig 17: class diagram for sensor
2.11.3 Flow Oriented Modeling
As knowledge flows through a computer-based system, it converts. In a variety of forms, the machine receives input, applies functions to transform it, and generates output in a variety of forms.
A control signal transmitted by a transducer can be the input, a number series typed by a human operator, an information packet transmitted over a network connection, or a voluminous data file retrieved from secondary storage.
A single logical comparison, a complex numerical algorithm, or an expert system's rule-inference approach can comprise the transform(s).
Key takeaways
- The first component of the model that is developed is mostly scenario-based elements of the requirements mode
- Each scenario of use involves a selection of artefacts that are manipulated as an actor communicates with the device.
- In a variety of forms, the machine receives input, applies functions to transform it, and generates output in a variety of forms.
- model specifications must have modelling components that reflect behaviour.
In the field of software engineering, UML stands for Unified Modeling Language, a structured general-purpose visual modelling language. It is used to define, visualize, build, and record the software system's primary objects. It helps to design and define, especially those software systems that implement the Object Orientation concept. It defines the operation of software as well as hardware systems.
The UML was developed by Rational Software's Grady Booch, Ivar Jacobson, and James Rumbaugh in 1994-95. In 1997, the Object Management Community adopted it as a standard (OMG).
The Object Management Group (OMG) is a multi-company organization which controls the open standard UML. The OMG was set up in order to develop an open standard that facilitates the interoperability of object-oriented systems in particular.
It is not limited to borders, but can also be used to model non-software structures. The OMG is best recognized according to the specifications of the Generic Object Request Broker Architecture (CORBA).
Goals of UML:
● Since it is a modelling language for general purposes, it can be used by all modelers.
● Due to the absence of standard methods at that time, UML came into existence after the introduction of object-oriented principles to systemize and consolidate object-oriented development.
● It can therefore be inferred that UML is a basic approach to modelling that is used to model all functional structures.
Characteristics of UML:
The UML has the following characteristics:
● It is a generalized language for modelling.
● It is different from programming languages such as C++, Python, etc.
● Object-oriented research and architecture are inter-related.
● It is used to simulate the system's workflow.
● It is a pictorial language that is used to create powerful objects for modelling.
Key takeaways
- UML stands for Unified Modeling Language, a structured general-purpose visual modelling language.
- It is used to define, visualize, build, and record the software system's primary objects.
References
- Roger Pressman, “Software Engineering:A Practitioner’s Approach”, McGraw Hill,ISBN 0-07-337597-7
- Ian Sommerville, “Software Engineering”,Addison and Wesley, ISBN 0-13-7035152
- Joseph Phillips, “IT Project Management-On Track From start to Finish”, Tata McGraw-Hill, ISBN13:978-0-07106727-0, ISBN-10:0-07-106727-2
- Pankaj Jalote, “Software Engineering: A Precise Approach”,Wiley India, ISBN: 9788-1265-2311-5
- Marchewka, “Information Technology Project Management”,Willey India, ISBN: 9788-1265-4394-6
- Rajib Mall, “Fundamentals of Software Engineering”,Prentice Hall India, ISBN-13:9788-1203-4898-1
