Unit - 4
Software requirement engineering
1. Requirement Engineering is the process of defining, documenting and maintaining the requirements. It is a process of gathering and defining service provided by the system. Requirements Engineering Process consists of the following main activities:
a) Requirements elicitation
b) Requirements specification
c) Requirements verification and validation
d) Requirements management
a) Requirements Elicitation:
1. It is related to the various ways used to gain knowledge about the project domain and requirements.
2. The various sources of domain knowledge include customers, business manuals, the existing software of same type, standards and other stakeholders of the project.
3. The techniques used for requirements elicitation include interviews, brainstorming, task analysis, Delphi technique, prototyping, etc. Some of these are discussed here.
4. Elicitation does not produce formal models of the requirements understood. Instead, it widens the domain knowledge of the analyst and thus helps in providing input to the next stage.
b) Requirements specification:
1. This activity is used to produce formal software requirement models.
2. All the requirements including the functional as well as the non-functional requirements and the constraints are specified by these models in totality.
3. During specification, more knowledge about the problem may be required which can again trigger the elicitation process.
4. The models used at this stage include ER diagrams, data flow diagrams(DFDs), function decomposition diagrams(FDDs), data dictionaries, etc.
c) Requirements verification and validation:
1. Verification: It refers to the set of tasks that ensures that the software correctly implements a specific function.
2. Validation: It refers to a different set of tasks that ensures that the software that has been built is traceable to customer requirements.
3. If requirements are not validated, errors in the requirement definitions would propagate to the successive stages resulting in a lot of modification and rework.
The main steps for this process include:
1 The requirements should be consistent with all the other
2 requirements i.e no two requirements should conflict with each other.
3 The requirements should be complete in every sense.
4 The requirements should be practically achievable.
d) Requirements management:
1. Requirement management is the process of analysing, documenting, tracking, prioritizing and agreeing on the requirement and controlling the communication to relevant stakeholders.
2. This stage takes care of the changing nature of requirements. It should be ensured that the SRS is as modifiable as possible so as to incorporate changes in requirements specified by the end users at later stages too.
3. Being able to modify the software as per requirements in a systematic and controlled manner is an extremely important part of the requirements engineering process.
Key takeaways:
1. It is a process of gathering and defining service provided by the system
2. It is related to the various ways used to gain knowledge about the project domain and requirements.
3. This activity is used to produce formal software requirement models.
4. If requirements are not validated, errors in the requirement definitions would propagate to the successive stages resulting in a lot of modification and rework.
5. Requirement management is the process of analysing, documenting, tracking, prioritizing and agreeing on the requirement and controlling the communication to relevant stakeholders.
Software requirement can be of 3 types:
1 Functional requirement
2 Non-functional requirements
3 Domain requirements
4.2.1 Functional Requirements:
1. These are the requirements that the end user specifically demands as basic facilities that the system should offer.
2. All these functionalities need to be necessarily incorporated into the system as a part of the contract.
3. These are represented or stated in the form of input to be given to the system, the operation performed and the output expected.
4. They are basically the requirements stated by the user which one can see directly in the final product, unlike the non-functional requirements.
4.2.2 Non-functional requirements:
1. These are basically the quality constraints that the system must satisfy according to the project contract.
2. The priority or extent to which these factors are implemented varies from one project to other. They are also called non-behavioural requirements.
3. They basically deal with issues like:
a) Portability
b) Security
c) Maintainability
d) Reliability
e) Scalability
f) Performance
g) Reusability
h) Flexibility
4. NFR’s are classified into following types:
a) Interface constraints
b) Performance constraints: response time, security, storage space, etc.
c) Operating constraints
d) Life cycle constraints: maintainability, portability, etc.
e) 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.
4.2.3 Domain requirements
1. Domain requirements are the requirements which are characteristic of a particular category or domain of projects.
2. The basic functions that a system of a specific domain must necessarily exhibit come under this category.
3. 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.
4. These requirements are therefore identified from that domain model and are not user specific.
Key takeaways:
1. These are the requirements that the end user specifically demands as basic facilities that the system should offer.
2. The priority or extent to which these factors are implemented varies from one project to other. They are also called non-behavioural requirements.
3. 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
4. The basic functions that a system of a specific domain must necessarily exhibit come under this category.
1. Quality of service (QoS) requirements specify how well a functional requirement shall be accomplished.
2. In real-time and embedded systems, QoS requirements may specify properties of the system (for example, range, speed, throughput, capacity, reliability, maintainability, evolvability, time to market, safety, predictability, schedulability), or properties of the process.
3. As a rule of thumb, if it's something that can be quantified or optimized, then it is a QoS requirement. For example (QoS requirements italicized):
a) The angle of the telescope shall be set in units of 0.1 degrees with a maximum error of 0.01 degrees.
b) The aesthetic agent shall be controllable from 0.00% to 5.00% by volume in units of 0.01% with an accuracy of 0.005%.
c) Locking clamps shall engage in the event of an elevator support cable breakage within less than 0.5 seconds.
d) The device shall alarm within 10 seconds if the heart rate falls below 30 beats per minute.
4. The defining characteristic of real-time systems is the level to which QoS timing requirements figure into the correctness of the system.
5. In non-real-time systems, late is acceptable. In real-time systems, late is unacceptable. Put another way, a real-time system is not necessarily fast, but it is predictably timely.
6. Of course, real-time systems may be hard real-time, which means that responses to events for aperiodic systems or actions taken when a periodic task begins (time-driven systems) must complete by a specified deadline.
7. Systems may also be soft real-time. For example:
a) Event responses shall be handled on average within a certain time.
b) A certain number of event responses shall be handled within a specified timeframe.
c) A specified failure rate is permitted.
Key takeaways:
1. Quality of service (QoS) requirements specify how well a functional requirement shall be accomplished.
2. As a rule of thumb, if it's something that can be quantified or optimized, then it is a QoS requirement. For example (QoS requirements italicized):
3. The aesthetic agent shall be controllable from 0.00% to 5.00% by volume in units of 0.01% with an accuracy of 0.005%.
4. Event responses shall be handled on average within a certain time.
1. Formal methods are system design techniques that use rigorously specified mathematical models to build software and hardware systems.
2. In contrast to other design systems, formal methods use mathematical proof as a complement to system testing in order to ensure correct behaviour.
3. As systems become more complicated, and safety becomes a more important issue, the formal approach to system design offers another level of insurance.
4. Formal methods differ from other design systems through the use of formal verification schemes, the basic principles of the system must be proven correct before they are accepted .
5. Traditional system design has used extensive testing to verify behavior, but testing is capable of only finite conclusions.
6. Dijkstra and others have demonstrated that tests can only show the situations where a system won't fail, but cannot say anything about the behavior of the system outside of the testing scenarios In contrast, once a theorem is proven true it remains true.
7. Roughly speaking, formal design can be seen as a three step process, following the outline given here:
a) Formal Specification: During the formal specification phase, the engineer rigorously defines a system using a modeling language. Modelling languages are fixed grammars which allow users to model complex structures out of predefined types. This process of formal specification is similar to the process of converting a word problem into algebraic notation.
b) Verification: As stated above, formal methods differ from other specification systems by their heavy emphasis on provability and correctness. By building a system using a formal specification, the designer is actually developing a set of theorems about his system. By proving these theorems correct, the formal.
c) Implementation: Once the model has been specified and verified, it is implemented by converting the specification into code. As the difference between software and hardware design grows narrower, formal methods for developing embedded systems have been developed. LARCH, for example, has a VHDL implementation. Similarly, hardware systems such as the VIPER and AAMP5 processors have been developed using formal approaches.
Key takeaways:
1. Formal methods are system design techniques that use rigorously specified mathematical models to build software and hardware systems.
2. Formal methods differ from other design systems through the use of formal verification schemes, the basic principles of the system must be proven correct before they are accepted.
3. This process of formal specification is similar to the process of converting a word problem into algebraic notation.
4. As the difference between software and hardware design grows narrower, formal methods for developing embedded systems have been developed.
1. Structured Analysis and Structured Design (SA/SD) is diagrammatic notation which is design to help people understand the system.
2. The basic goal of SA/SD is to improve quality and reduce the risk of System failure. It establishes concrete management specification and documentation. It focuses on solidity, pliability and maintainability of system.
3. Basically the approach of SA/SD is based on the Data Flow Diagram. It is easy to understand SA/SD but it focuses on well defined system boundary whereas JSD approach is too complex and does not have any graphical representation.
4. SA/SD is combined known as SAD and it mainly focuses on following 3 points:
a) System
b) Process
c) Technology
5. SA/SD involves 2 phases:
1) Analysis Phase: It uses Data Flow Diagram, Data Dictionary, State Transition diagram and ER diagram.
2) Design Phase: It uses Structure Chart and Pseudo Code.
- Data Flow Diagram:
1. In the data flow diagram model describe how the data flows through the system. We can incorporate the Boolean operators and & or to link data flows when more than one data flow may be input or output from a process.
For example, if we have to choose between two paths of a process we can add an operator or and if two data flows are necessary for a process we can add and operator. The input of the process “check-order” needs the credit information and order information whereas the output of the process would be a cash-order or a good-credit-order.
B. Data Dictionary:
1. The content that are not described in the DFD are described in data dictionary. It defines the data store and relevant meaning.
2. A physical data dictionary for data elements which flow between processes, between entities, and between processes and entities may be included. This would also include descriptions of data elements that flow external to the data stores.
3. A logical data dictionary may also be included for each such data element. All system names, whether they are names of entities, types, relations, attributes or services, should be entered in the dictionary.
C. State Transition Diagram:
1. State transition diagram is similar to dynamic model. It specifies how much time function will take to execute and data access triggered by events.
2. It also describes all of the states that an object can have, the events under which an object changes state, the conditions that must be fulfilled before the transition will occur and the activities undertaken during the life of an object.
D. ER Diagram:
1. ER diagram specifies the relationship between data store. It is basically used in database design. It basically describes the relationship between different entities.
2) Design Phase:
Design Phase involves structure chart and pseudo code.
a) Structure Chart:
1. It is created by the data flow diagram. Structure Chart specifies how DFS’s processes are grouped into task and allocate to CPU.
2. The structured chart does not show the working and internal structure of the processes or modules, and does not show the relationship between data or data-flows.
3. Similar to other SASD tools, it is time and cost independent and there is no error-checking technique associated with this tool.
4. The modules of a structured chart are arranged arbitrarily and any process from a DFD can be chosen as the central transform depending on the analysts’ own perception.
6. The structured chart is difficult to amend, verify, maintain, and check for completeness and consistency.
b) Pseudo Code:
It is actual implementation of system. It is an informal way of programming which doesn’t require any specific programming language or technology.
Key takeaways:
1. Structured Analysis and Structured Design (SA/SD) is diagrammatic notation which is design to help people understand the system.
2. It is easy to understand SA/SD but it focuses on well-defined system boundary whereas JSD approach is too complex and does not have any graphical representation.
3. In the data flow diagram model describe how the data flows through the system.
4. A physical data dictionary for data elements which flow between processes, between entities, and between processes and entities may be included.
5. It also describes all of the states that an object can have, the events under which an object changes state, the conditions that must be fulfilled before the transition will occur and the activities undertaken during the life of an object.
6. Similar to other SASD tools, it is time and cost independent and there is no error-checking technique associated with this tool.
7. It is actual implementation of system. It is an informal way of programming which doesn’t require any specific programming language or technology
4.6.1 Unified modelling language
1. UML is a standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems.
2. UML was created by the Object Management Group (OMG) and UML 1.0 specification draft was proposed to the OMG in January 1997.
3. OMG is continuously making efforts to create a truly industry standard.
a) UML stands for Unified Modelling Language.
b) UML is different from the other common programming languages such as C++, Java, COBOL, etc.
c) UML is a pictorial language used to make software blueprints.
d) UML can be described as a general purpose visual modeling language to visualize, specify, construct, and document software system.
e) Although UML is generally used to model software systems, it is not limited within this boundary. It is also used to model non-software systems as well. For example, the process flow in a manufacturing unit, etc.
4. UML is not a programming language but tools can be used to generate code in various languages using UML diagrams. UML has a direct relation with object oriented analysis and design. After some standardization, UML has become an OMG standard.
4.6.2 Object-Oriented Concepts
1. UML can be described as the successor of object-oriented (OO) analysis and design.
2. An object contains both data and methods that control the data. The data represents the state of the object. A class describes an object and they also form a hierarchy to model the real-world system.
3. The hierarchy is represented as inheritance and the classes can also be associated in different ways as per the requirement.
4. Objects are the real-world entities that exist around us and the basic concepts such as abstraction, encapsulation, inheritance, and polymorphism all can be represented using UML.
5. UML is powerful enough to represent all the concepts that exist in object-oriented analysis and design. UML diagrams are representation of object-oriented concepts only. Thus, before learning UML, it becomes important to understand OO concept in detail.
Following are some fundamental concepts of the object-oriented world −
a) Objects − Objects represent an entity and the basic building block.
b) Class − Class is the blue print of an object.
c) Abstraction − Abstraction represents the behavior of an real world entity.
d) Encapsulation − Encapsulation is the mechanism of binding the data together and hiding them from the outside world.
e) Inheritance − Inheritance is the mechanism of making new classes from existing ones.
f) Polymorphism − It defines the mechanism to exists in different forms.
6. OO Analysis and Design OO can be defined as an investigation and to be more specific, it is the investigation of objects. Design means collaboration of identified objects.
7. Thus, it is important to understand the OO analysis and design concepts. The most important purpose of OO analysis is to identify objects of a system to be designed.
8. This analysis is also done for an existing system. Now an efficient analysis is only possible when we are able to start thinking in a way where objects can be identified. After identifying the objects, their relationships are identified and finally the design is produced.
The purpose of OO analysis and design can described as –
a) Identifying the objects of a system.
b) Identifying their relationships.
c) Making a design, which can be converted to executable using OO languages?
There are three basic steps where the OO concepts are applied and implemented. The steps can be defined as
OO Analysis → OO Design → OO implementation using OO languages
The above three points can be described in detail as −
9. During OO analysis, the most important purpose is to identify objects and describe them in a proper way. If these objects are identified efficiently, then the next job of design is easy.
10. The objects should be identified with responsibilities. Responsibilities are the functions performed by the object. Each and every object has some type of responsibilities to be performed. When these responsibilities are collaborated, the purpose of the system is fulfilled.
11. The second phase is OO design. During this phase, emphasis is placed on the requirements and their fulfilment. In this stage, the objects are collaborated according to their intended association. After the association is complete, the design is also complete.
12. The third phase is OO implementation. In this phase, the design is implemented using OO languages such as Java, C++, etc.
13. Role of UML in OO Design
UML is a modeling language used to model software and non-software systems. Although UML is used for non-software systems, the emphasis is on modeling OO software applications. Most of the UML diagrams discussed so far are used to model different aspects such as static, dynamic, etc. Now whatever be the aspect, the artifacts are nothing but objects.
Key takeaways:
1. UML is a standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems.
2. UML can be described as a general purpose visual modeling language to visualize, specify, construct, and document software system.
3. An object contains both data and methods that control the data. The data represents the state of the object. A class describes an object and they also form a hierarchy to model the real-world system.
4. OO Analysis and Design OO can be defined as an investigation and to be more specific, it is the investigation of objects. Design means collaboration of identified objects
5. During OO analysis, the most important purpose is to identify objects and describe them in a proper way. If these objects are identified efficiently, then the next job of design is easy.
6. UML is a modeling language used to model software and non-software systems. Although UML is used for non-software systems, the emphasis is on modeling OO software applications.
1. Documentation ensures that the software development team or other stakeholders are on the same page regarding what needs to be built and are fully aware of the goal, scope, functional requirements, challenges, and budget regarding the software.
2. However, as much as creating software is exciting, documenting its requirements can be boring and tiresome.
3. A software requirements document (also known as software requirements specifications) is a document that describes the intended use-case, features, and challenges of a software application.
4. These documents are created before the project has started development in order to get every stakeholder on the same page regarding the software’s functionality.
5. Software requirements are written up by the tech team depending on the project they are working on. As non-technical colleagues, clients, and partners get involved it’s important to ensure that everyone is on the same page and agree with the scope, budget, and goal of the project.
6. Software requirement documents provide an important map of the product being built, the features that will be included, and much more.
7. This roadmap helps to keep the technical and non-technical team on the same wavelength as to what the expectations are. It helps to ensure that the product is built meeting the needs whether it’s for internal purposes, for users or clients.
Key takeaways:
1. Documentation ensures that the software development team or other stakeholders are on the same page regarding what needs to be built and are fully aware of the goal, scope, functional requirements, challenges, and budget regarding the software.
2. These documents are created before the project has started development in order to get every stakeholder on the same page regarding the software’s functionality.
3. It helps to ensure that the product is built meeting the needs whether it’s for internal purposes, for users or clients.
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 all stakeholders (business, users) needs.
A typical SRS includes:
1. A purpose
2. An overall description
3. Specific requirements
Your first step is to create an outline for your software requirements specification. This may be something you create yourself. Or you may use an existing SRS template.
If you’re creating this yourself, here’s what your outline might look like:
1. Start with a Purpose
The introduction to your SRS is very important. It sets the expectation for the product you’re building.
So, start by defining the purpose of your product.
2. Give an Overview of What You’ll Build
a) Your next step is to give a description of what you’re going to build. Is it an update to an existing product? Is it a new product? Is it an add-on to a product you’ve already created?
b) These are important to describe upfront, so everyone knows what you’re building.
You should also describe why you’re building it and who it’s for. User Needs and Assumptions and Dependencies
3. Detail Your Specific Requirements
The next section is key for your development team. This is where you detail the specific requirements for building your product.
a) Functional Requirements
Functional requirements are essential to building your product.
If you’re developing a medical device, these requirements may include infusion and battery. And within these functional requirements, you may have a subset of risks and requirements.
b) External Interface Requirements
External interface requirements are types of functional requirements. They’re important for embedded systems. And they outline how your product will interface with other components.
There are several types of interfaces you may have requirements for, including:
1) User
2) Hardware
3) Software
4) Communications
4. System Features
System features are types of functional requirements. These are features that are required in order for a system to function
Key takeaways:
1. A software requirements specification (SRS) is a document that describes what the software will do and how it will be expected to perform.
2. Your first step is to create an outline for your software requirements specification.
3. The introduction to your SRS is very important. It sets the expectation for the product you’re building.
4. You should also describe why you’re building it and who it’s for.
5. If you’re developing a medical device, these requirements may include infusion and battery
6. External interface requirements are types of functional requirements. They’re important for embedded systems
4.9.1 Requirements Validation
1. It’s a process of ensuring the specified requirements meet the customer needs. It’s concerned with finding problems with the requirements.
2. These problems can lead to extensive rework costs when these they are discovered in the later stages, or after the system is in service.
3. The cost of fixing a requirements problem by making a system change is usually much greater than repairing design or code errors. Because a change to the requirements usually means the design and implementation must also be changed, and re-tested.
4. During the requirements validation process, different types of checks should be carried out on the requirements. These checks include:
a) Validity checks: The functions proposed by stakeholders should be aligned with what the system needs to perform. You may find later that there are additional or different functions are required instead.
b) Consistency checks: Requirements in the document shouldn’t conflict or different description of the same function
c) Completeness checks: The document should include all the requirements and constrains.
d) Realism checks: Ensure the requirements can actually be implemented using the knowledge of existing technology, the budget, schedule, etc.
5. Verifiability: Requirements should be written so that they can be tested. This means you should be able to write a set of tests that demonstrate that the system meets the specified requirements.
6. There are some techniques you can use to validate the requirements, and you may use one or more of them together, depending on your needs.
4.9.2 Requirements Reviews
1. A team of system customer; those who interact with the customer to gather requirements, and system developers start reading the requirements in the document, and investigate in a great detail to check for errors, inconsistency, conflicts, and any ambiguity.
2. Then they may negotiate with the customer on how to solve the problems and errors found.
3. Prototyping
a) We’ve discussed the prototyping as one of the (non-standalone) software process methodology, which used as part of a full methodologies, and we’ve also mentioned in can be used in the requirements engineering.
b) In this approach to validation, an executable model of the system is demonstrated to the customer and end users to validate, and ensure if it meets their needs.
c) Prototyping is usually used when the requirements aren’t clear. So, we make a quick design of the system to validate the requirements. If it fails, we then refine it, and check again, until it meets the customer needs.
d) This definitely will decrease the cost as a result of having a clear, understandable, consistent requirements.
Key takeaways:
1. It’s a process of ensuring the specified requirements meet the customer needs
2. These problems can lead to extensive rework costs when these they are discovered in the later stages, or after the system is in service
3. Verifiability: Requirements should be written so that they can be tested. This means you should be able to write a set of tests that demonstrate that the system meets the specified requirements.
4. A team of system customer; those who interact with the customer to gather requirements, and system developers start reading the requirements in the document, and investigate in a great detail to check for errors, inconsistency, conflicts, and any ambiguity.
5. This definitely will decrease the cost as a result of having clear, understandable, consistent requirements.
References:
- Real- Time Systems Design and Analysis.. Tools for the Practitioner by Phillip A Laplante, Seppo J.Ovaska ,Wiley - 4th Edition
- Embedded Real Time Systems: Concepts, Design and Programming - Dr. K.V.K. Prasad -Black Book, Edition: 2014
- Real Time Systems Theory and Practice , Rajib Mall , Pearson Education
Unit - 4
Software requirement engineering
1. Requirement Engineering is the process of defining, documenting and maintaining the requirements. It is a process of gathering and defining service provided by the system. Requirements Engineering Process consists of the following main activities:
a) Requirements elicitation
b) Requirements specification
c) Requirements verification and validation
d) Requirements management
a) Requirements Elicitation:
1. It is related to the various ways used to gain knowledge about the project domain and requirements.
2. The various sources of domain knowledge include customers, business manuals, the existing software of same type, standards and other stakeholders of the project.
3. The techniques used for requirements elicitation include interviews, brainstorming, task analysis, Delphi technique, prototyping, etc. Some of these are discussed here.
4. Elicitation does not produce formal models of the requirements understood. Instead, it widens the domain knowledge of the analyst and thus helps in providing input to the next stage.
b) Requirements specification:
1. This activity is used to produce formal software requirement models.
2. All the requirements including the functional as well as the non-functional requirements and the constraints are specified by these models in totality.
3. During specification, more knowledge about the problem may be required which can again trigger the elicitation process.
4. The models used at this stage include ER diagrams, data flow diagrams(DFDs), function decomposition diagrams(FDDs), data dictionaries, etc.
c) Requirements verification and validation:
1. Verification: It refers to the set of tasks that ensures that the software correctly implements a specific function.
2. Validation: It refers to a different set of tasks that ensures that the software that has been built is traceable to customer requirements.
3. If requirements are not validated, errors in the requirement definitions would propagate to the successive stages resulting in a lot of modification and rework.
The main steps for this process include:
1 The requirements should be consistent with all the other
2 requirements i.e no two requirements should conflict with each other.
3 The requirements should be complete in every sense.
4 The requirements should be practically achievable.
d) Requirements management:
1. Requirement management is the process of analysing, documenting, tracking, prioritizing and agreeing on the requirement and controlling the communication to relevant stakeholders.
2. This stage takes care of the changing nature of requirements. It should be ensured that the SRS is as modifiable as possible so as to incorporate changes in requirements specified by the end users at later stages too.
3. Being able to modify the software as per requirements in a systematic and controlled manner is an extremely important part of the requirements engineering process.
Key takeaways:
1. It is a process of gathering and defining service provided by the system
2. It is related to the various ways used to gain knowledge about the project domain and requirements.
3. This activity is used to produce formal software requirement models.
4. If requirements are not validated, errors in the requirement definitions would propagate to the successive stages resulting in a lot of modification and rework.
5. Requirement management is the process of analysing, documenting, tracking, prioritizing and agreeing on the requirement and controlling the communication to relevant stakeholders.
Software requirement can be of 3 types:
1 Functional requirement
2 Non-functional requirements
3 Domain requirements
4.2.1 Functional Requirements:
1. These are the requirements that the end user specifically demands as basic facilities that the system should offer.
2. All these functionalities need to be necessarily incorporated into the system as a part of the contract.
3. These are represented or stated in the form of input to be given to the system, the operation performed and the output expected.
4. They are basically the requirements stated by the user which one can see directly in the final product, unlike the non-functional requirements.
4.2.2 Non-functional requirements:
1. These are basically the quality constraints that the system must satisfy according to the project contract.
2. The priority or extent to which these factors are implemented varies from one project to other. They are also called non-behavioural requirements.
3. They basically deal with issues like:
a) Portability
b) Security
c) Maintainability
d) Reliability
e) Scalability
f) Performance
g) Reusability
h) Flexibility
4. NFR’s are classified into following types:
a) Interface constraints
b) Performance constraints: response time, security, storage space, etc.
c) Operating constraints
d) Life cycle constraints: maintainability, portability, etc.
e) 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.
4.2.3 Domain requirements
1. Domain requirements are the requirements which are characteristic of a particular category or domain of projects.
2. The basic functions that a system of a specific domain must necessarily exhibit come under this category.
3. 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.
4. These requirements are therefore identified from that domain model and are not user specific.
Key takeaways:
1. These are the requirements that the end user specifically demands as basic facilities that the system should offer.
2. The priority or extent to which these factors are implemented varies from one project to other. They are also called non-behavioural requirements.
3. 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
4. The basic functions that a system of a specific domain must necessarily exhibit come under this category.
1. Quality of service (QoS) requirements specify how well a functional requirement shall be accomplished.
2. In real-time and embedded systems, QoS requirements may specify properties of the system (for example, range, speed, throughput, capacity, reliability, maintainability, evolvability, time to market, safety, predictability, schedulability), or properties of the process.
3. As a rule of thumb, if it's something that can be quantified or optimized, then it is a QoS requirement. For example (QoS requirements italicized):
a) The angle of the telescope shall be set in units of 0.1 degrees with a maximum error of 0.01 degrees.
b) The aesthetic agent shall be controllable from 0.00% to 5.00% by volume in units of 0.01% with an accuracy of 0.005%.
c) Locking clamps shall engage in the event of an elevator support cable breakage within less than 0.5 seconds.
d) The device shall alarm within 10 seconds if the heart rate falls below 30 beats per minute.
4. The defining characteristic of real-time systems is the level to which QoS timing requirements figure into the correctness of the system.
5. In non-real-time systems, late is acceptable. In real-time systems, late is unacceptable. Put another way, a real-time system is not necessarily fast, but it is predictably timely.
6. Of course, real-time systems may be hard real-time, which means that responses to events for aperiodic systems or actions taken when a periodic task begins (time-driven systems) must complete by a specified deadline.
7. Systems may also be soft real-time. For example:
a) Event responses shall be handled on average within a certain time.
b) A certain number of event responses shall be handled within a specified timeframe.
c) A specified failure rate is permitted.
Key takeaways:
1. Quality of service (QoS) requirements specify how well a functional requirement shall be accomplished.
2. As a rule of thumb, if it's something that can be quantified or optimized, then it is a QoS requirement. For example (QoS requirements italicized):
3. The aesthetic agent shall be controllable from 0.00% to 5.00% by volume in units of 0.01% with an accuracy of 0.005%.
4. Event responses shall be handled on average within a certain time.
1. Formal methods are system design techniques that use rigorously specified mathematical models to build software and hardware systems.
2. In contrast to other design systems, formal methods use mathematical proof as a complement to system testing in order to ensure correct behaviour.
3. As systems become more complicated, and safety becomes a more important issue, the formal approach to system design offers another level of insurance.
4. Formal methods differ from other design systems through the use of formal verification schemes, the basic principles of the system must be proven correct before they are accepted .
5. Traditional system design has used extensive testing to verify behavior, but testing is capable of only finite conclusions.
6. Dijkstra and others have demonstrated that tests can only show the situations where a system won't fail, but cannot say anything about the behavior of the system outside of the testing scenarios In contrast, once a theorem is proven true it remains true.
7. Roughly speaking, formal design can be seen as a three step process, following the outline given here:
a) Formal Specification: During the formal specification phase, the engineer rigorously defines a system using a modeling language. Modelling languages are fixed grammars which allow users to model complex structures out of predefined types. This process of formal specification is similar to the process of converting a word problem into algebraic notation.
b) Verification: As stated above, formal methods differ from other specification systems by their heavy emphasis on provability and correctness. By building a system using a formal specification, the designer is actually developing a set of theorems about his system. By proving these theorems correct, the formal.
c) Implementation: Once the model has been specified and verified, it is implemented by converting the specification into code. As the difference between software and hardware design grows narrower, formal methods for developing embedded systems have been developed. LARCH, for example, has a VHDL implementation. Similarly, hardware systems such as the VIPER and AAMP5 processors have been developed using formal approaches.
Key takeaways:
1. Formal methods are system design techniques that use rigorously specified mathematical models to build software and hardware systems.
2. Formal methods differ from other design systems through the use of formal verification schemes, the basic principles of the system must be proven correct before they are accepted.
3. This process of formal specification is similar to the process of converting a word problem into algebraic notation.
4. As the difference between software and hardware design grows narrower, formal methods for developing embedded systems have been developed.
1. Structured Analysis and Structured Design (SA/SD) is diagrammatic notation which is design to help people understand the system.
2. The basic goal of SA/SD is to improve quality and reduce the risk of System failure. It establishes concrete management specification and documentation. It focuses on solidity, pliability and maintainability of system.
3. Basically the approach of SA/SD is based on the Data Flow Diagram. It is easy to understand SA/SD but it focuses on well defined system boundary whereas JSD approach is too complex and does not have any graphical representation.
4. SA/SD is combined known as SAD and it mainly focuses on following 3 points:
a) System
b) Process
c) Technology
5. SA/SD involves 2 phases:
1) Analysis Phase: It uses Data Flow Diagram, Data Dictionary, State Transition diagram and ER diagram.
2) Design Phase: It uses Structure Chart and Pseudo Code.
- Data Flow Diagram:
1. In the data flow diagram model describe how the data flows through the system. We can incorporate the Boolean operators and & or to link data flows when more than one data flow may be input or output from a process.
For example, if we have to choose between two paths of a process we can add an operator or and if two data flows are necessary for a process we can add and operator. The input of the process “check-order” needs the credit information and order information whereas the output of the process would be a cash-order or a good-credit-order.
B. Data Dictionary:
1. The content that are not described in the DFD are described in data dictionary. It defines the data store and relevant meaning.
2. A physical data dictionary for data elements which flow between processes, between entities, and between processes and entities may be included. This would also include descriptions of data elements that flow external to the data stores.
3. A logical data dictionary may also be included for each such data element. All system names, whether they are names of entities, types, relations, attributes or services, should be entered in the dictionary.
C. State Transition Diagram:
1. State transition diagram is similar to dynamic model. It specifies how much time function will take to execute and data access triggered by events.
2. It also describes all of the states that an object can have, the events under which an object changes state, the conditions that must be fulfilled before the transition will occur and the activities undertaken during the life of an object.
D. ER Diagram:
1. ER diagram specifies the relationship between data store. It is basically used in database design. It basically describes the relationship between different entities.
2) Design Phase:
Design Phase involves structure chart and pseudo code.
a) Structure Chart:
1. It is created by the data flow diagram. Structure Chart specifies how DFS’s processes are grouped into task and allocate to CPU.
2. The structured chart does not show the working and internal structure of the processes or modules, and does not show the relationship between data or data-flows.
3. Similar to other SASD tools, it is time and cost independent and there is no error-checking technique associated with this tool.
4. The modules of a structured chart are arranged arbitrarily and any process from a DFD can be chosen as the central transform depending on the analysts’ own perception.
6. The structured chart is difficult to amend, verify, maintain, and check for completeness and consistency.
b) Pseudo Code:
It is actual implementation of system. It is an informal way of programming which doesn’t require any specific programming language or technology.
Key takeaways:
1. Structured Analysis and Structured Design (SA/SD) is diagrammatic notation which is design to help people understand the system.
2. It is easy to understand SA/SD but it focuses on well-defined system boundary whereas JSD approach is too complex and does not have any graphical representation.
3. In the data flow diagram model describe how the data flows through the system.
4. A physical data dictionary for data elements which flow between processes, between entities, and between processes and entities may be included.
5. It also describes all of the states that an object can have, the events under which an object changes state, the conditions that must be fulfilled before the transition will occur and the activities undertaken during the life of an object.
6. Similar to other SASD tools, it is time and cost independent and there is no error-checking technique associated with this tool.
7. It is actual implementation of system. It is an informal way of programming which doesn’t require any specific programming language or technology
4.6.1 Unified modelling language
1. UML is a standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems.
2. UML was created by the Object Management Group (OMG) and UML 1.0 specification draft was proposed to the OMG in January 1997.
3. OMG is continuously making efforts to create a truly industry standard.
a) UML stands for Unified Modelling Language.
b) UML is different from the other common programming languages such as C++, Java, COBOL, etc.
c) UML is a pictorial language used to make software blueprints.
d) UML can be described as a general purpose visual modeling language to visualize, specify, construct, and document software system.
e) Although UML is generally used to model software systems, it is not limited within this boundary. It is also used to model non-software systems as well. For example, the process flow in a manufacturing unit, etc.
4. UML is not a programming language but tools can be used to generate code in various languages using UML diagrams. UML has a direct relation with object oriented analysis and design. After some standardization, UML has become an OMG standard.
4.6.2 Object-Oriented Concepts
1. UML can be described as the successor of object-oriented (OO) analysis and design.
2. An object contains both data and methods that control the data. The data represents the state of the object. A class describes an object and they also form a hierarchy to model the real-world system.
3. The hierarchy is represented as inheritance and the classes can also be associated in different ways as per the requirement.
4. Objects are the real-world entities that exist around us and the basic concepts such as abstraction, encapsulation, inheritance, and polymorphism all can be represented using UML.
5. UML is powerful enough to represent all the concepts that exist in object-oriented analysis and design. UML diagrams are representation of object-oriented concepts only. Thus, before learning UML, it becomes important to understand OO concept in detail.
Following are some fundamental concepts of the object-oriented world −
a) Objects − Objects represent an entity and the basic building block.
b) Class − Class is the blue print of an object.
c) Abstraction − Abstraction represents the behavior of an real world entity.
d) Encapsulation − Encapsulation is the mechanism of binding the data together and hiding them from the outside world.
e) Inheritance − Inheritance is the mechanism of making new classes from existing ones.
f) Polymorphism − It defines the mechanism to exists in different forms.
6. OO Analysis and Design OO can be defined as an investigation and to be more specific, it is the investigation of objects. Design means collaboration of identified objects.
7. Thus, it is important to understand the OO analysis and design concepts. The most important purpose of OO analysis is to identify objects of a system to be designed.
8. This analysis is also done for an existing system. Now an efficient analysis is only possible when we are able to start thinking in a way where objects can be identified. After identifying the objects, their relationships are identified and finally the design is produced.
The purpose of OO analysis and design can described as –
a) Identifying the objects of a system.
b) Identifying their relationships.
c) Making a design, which can be converted to executable using OO languages?
There are three basic steps where the OO concepts are applied and implemented. The steps can be defined as
OO Analysis → OO Design → OO implementation using OO languages
The above three points can be described in detail as −
9. During OO analysis, the most important purpose is to identify objects and describe them in a proper way. If these objects are identified efficiently, then the next job of design is easy.
10. The objects should be identified with responsibilities. Responsibilities are the functions performed by the object. Each and every object has some type of responsibilities to be performed. When these responsibilities are collaborated, the purpose of the system is fulfilled.
11. The second phase is OO design. During this phase, emphasis is placed on the requirements and their fulfilment. In this stage, the objects are collaborated according to their intended association. After the association is complete, the design is also complete.
12. The third phase is OO implementation. In this phase, the design is implemented using OO languages such as Java, C++, etc.
13. Role of UML in OO Design
UML is a modeling language used to model software and non-software systems. Although UML is used for non-software systems, the emphasis is on modeling OO software applications. Most of the UML diagrams discussed so far are used to model different aspects such as static, dynamic, etc. Now whatever be the aspect, the artifacts are nothing but objects.
Key takeaways:
1. UML is a standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems.
2. UML can be described as a general purpose visual modeling language to visualize, specify, construct, and document software system.
3. An object contains both data and methods that control the data. The data represents the state of the object. A class describes an object and they also form a hierarchy to model the real-world system.
4. OO Analysis and Design OO can be defined as an investigation and to be more specific, it is the investigation of objects. Design means collaboration of identified objects
5. During OO analysis, the most important purpose is to identify objects and describe them in a proper way. If these objects are identified efficiently, then the next job of design is easy.
6. UML is a modeling language used to model software and non-software systems. Although UML is used for non-software systems, the emphasis is on modeling OO software applications.
1. Documentation ensures that the software development team or other stakeholders are on the same page regarding what needs to be built and are fully aware of the goal, scope, functional requirements, challenges, and budget regarding the software.
2. However, as much as creating software is exciting, documenting its requirements can be boring and tiresome.
3. A software requirements document (also known as software requirements specifications) is a document that describes the intended use-case, features, and challenges of a software application.
4. These documents are created before the project has started development in order to get every stakeholder on the same page regarding the software’s functionality.
5. Software requirements are written up by the tech team depending on the project they are working on. As non-technical colleagues, clients, and partners get involved it’s important to ensure that everyone is on the same page and agree with the scope, budget, and goal of the project.
6. Software requirement documents provide an important map of the product being built, the features that will be included, and much more.
7. This roadmap helps to keep the technical and non-technical team on the same wavelength as to what the expectations are. It helps to ensure that the product is built meeting the needs whether it’s for internal purposes, for users or clients.
Key takeaways:
1. Documentation ensures that the software development team or other stakeholders are on the same page regarding what needs to be built and are fully aware of the goal, scope, functional requirements, challenges, and budget regarding the software.
2. These documents are created before the project has started development in order to get every stakeholder on the same page regarding the software’s functionality.
3. It helps to ensure that the product is built meeting the needs whether it’s for internal purposes, for users or clients.
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 all stakeholders (business, users) needs.
A typical SRS includes:
1. A purpose
2. An overall description
3. Specific requirements
Your first step is to create an outline for your software requirements specification. This may be something you create yourself. Or you may use an existing SRS template.
If you’re creating this yourself, here’s what your outline might look like:
1. Start with a Purpose
The introduction to your SRS is very important. It sets the expectation for the product you’re building.
So, start by defining the purpose of your product.
2. Give an Overview of What You’ll Build
a) Your next step is to give a description of what you’re going to build. Is it an update to an existing product? Is it a new product? Is it an add-on to a product you’ve already created?
b) These are important to describe upfront, so everyone knows what you’re building.
You should also describe why you’re building it and who it’s for. User Needs and Assumptions and Dependencies
3. Detail Your Specific Requirements
The next section is key for your development team. This is where you detail the specific requirements for building your product.
a) Functional Requirements
Functional requirements are essential to building your product.
If you’re developing a medical device, these requirements may include infusion and battery. And within these functional requirements, you may have a subset of risks and requirements.
b) External Interface Requirements
External interface requirements are types of functional requirements. They’re important for embedded systems. And they outline how your product will interface with other components.
There are several types of interfaces you may have requirements for, including:
1) User
2) Hardware
3) Software
4) Communications
4. System Features
System features are types of functional requirements. These are features that are required in order for a system to function
Key takeaways:
1. A software requirements specification (SRS) is a document that describes what the software will do and how it will be expected to perform.
2. Your first step is to create an outline for your software requirements specification.
3. The introduction to your SRS is very important. It sets the expectation for the product you’re building.
4. You should also describe why you’re building it and who it’s for.
5. If you’re developing a medical device, these requirements may include infusion and battery
6. External interface requirements are types of functional requirements. They’re important for embedded systems
4.9.1 Requirements Validation
1. It’s a process of ensuring the specified requirements meet the customer needs. It’s concerned with finding problems with the requirements.
2. These problems can lead to extensive rework costs when these they are discovered in the later stages, or after the system is in service.
3. The cost of fixing a requirements problem by making a system change is usually much greater than repairing design or code errors. Because a change to the requirements usually means the design and implementation must also be changed, and re-tested.
4. During the requirements validation process, different types of checks should be carried out on the requirements. These checks include:
a) Validity checks: The functions proposed by stakeholders should be aligned with what the system needs to perform. You may find later that there are additional or different functions are required instead.
b) Consistency checks: Requirements in the document shouldn’t conflict or different description of the same function
c) Completeness checks: The document should include all the requirements and constrains.
d) Realism checks: Ensure the requirements can actually be implemented using the knowledge of existing technology, the budget, schedule, etc.
5. Verifiability: Requirements should be written so that they can be tested. This means you should be able to write a set of tests that demonstrate that the system meets the specified requirements.
6. There are some techniques you can use to validate the requirements, and you may use one or more of them together, depending on your needs.
4.9.2 Requirements Reviews
1. A team of system customer; those who interact with the customer to gather requirements, and system developers start reading the requirements in the document, and investigate in a great detail to check for errors, inconsistency, conflicts, and any ambiguity.
2. Then they may negotiate with the customer on how to solve the problems and errors found.
3. Prototyping
a) We’ve discussed the prototyping as one of the (non-standalone) software process methodology, which used as part of a full methodologies, and we’ve also mentioned in can be used in the requirements engineering.
b) In this approach to validation, an executable model of the system is demonstrated to the customer and end users to validate, and ensure if it meets their needs.
c) Prototyping is usually used when the requirements aren’t clear. So, we make a quick design of the system to validate the requirements. If it fails, we then refine it, and check again, until it meets the customer needs.
d) This definitely will decrease the cost as a result of having a clear, understandable, consistent requirements.
Key takeaways:
1. It’s a process of ensuring the specified requirements meet the customer needs
2. These problems can lead to extensive rework costs when these they are discovered in the later stages, or after the system is in service
3. Verifiability: Requirements should be written so that they can be tested. This means you should be able to write a set of tests that demonstrate that the system meets the specified requirements.
4. A team of system customer; those who interact with the customer to gather requirements, and system developers start reading the requirements in the document, and investigate in a great detail to check for errors, inconsistency, conflicts, and any ambiguity.
5. This definitely will decrease the cost as a result of having clear, understandable, consistent requirements.
References:
- Real- Time Systems Design and Analysis.. Tools for the Practitioner by Phillip A Laplante, Seppo J.Ovaska ,Wiley - 4th Edition
- Embedded Real Time Systems: Concepts, Design and Programming - Dr. K.V.K. Prasad -Black Book, Edition: 2014
- Real Time Systems Theory and Practice , Rajib Mall , Pearson Education
Unit - 4
Software requirement engineering
1. Requirement Engineering is the process of defining, documenting and maintaining the requirements. It is a process of gathering and defining service provided by the system. Requirements Engineering Process consists of the following main activities:
a) Requirements elicitation
b) Requirements specification
c) Requirements verification and validation
d) Requirements management
a) Requirements Elicitation:
1. It is related to the various ways used to gain knowledge about the project domain and requirements.
2. The various sources of domain knowledge include customers, business manuals, the existing software of same type, standards and other stakeholders of the project.
3. The techniques used for requirements elicitation include interviews, brainstorming, task analysis, Delphi technique, prototyping, etc. Some of these are discussed here.
4. Elicitation does not produce formal models of the requirements understood. Instead, it widens the domain knowledge of the analyst and thus helps in providing input to the next stage.
b) Requirements specification:
1. This activity is used to produce formal software requirement models.
2. All the requirements including the functional as well as the non-functional requirements and the constraints are specified by these models in totality.
3. During specification, more knowledge about the problem may be required which can again trigger the elicitation process.
4. The models used at this stage include ER diagrams, data flow diagrams(DFDs), function decomposition diagrams(FDDs), data dictionaries, etc.
c) Requirements verification and validation:
1. Verification: It refers to the set of tasks that ensures that the software correctly implements a specific function.
2. Validation: It refers to a different set of tasks that ensures that the software that has been built is traceable to customer requirements.
3. If requirements are not validated, errors in the requirement definitions would propagate to the successive stages resulting in a lot of modification and rework.
The main steps for this process include:
1 The requirements should be consistent with all the other
2 requirements i.e no two requirements should conflict with each other.
3 The requirements should be complete in every sense.
4 The requirements should be practically achievable.
d) Requirements management:
1. Requirement management is the process of analysing, documenting, tracking, prioritizing and agreeing on the requirement and controlling the communication to relevant stakeholders.
2. This stage takes care of the changing nature of requirements. It should be ensured that the SRS is as modifiable as possible so as to incorporate changes in requirements specified by the end users at later stages too.
3. Being able to modify the software as per requirements in a systematic and controlled manner is an extremely important part of the requirements engineering process.
Key takeaways:
1. It is a process of gathering and defining service provided by the system
2. It is related to the various ways used to gain knowledge about the project domain and requirements.
3. This activity is used to produce formal software requirement models.
4. If requirements are not validated, errors in the requirement definitions would propagate to the successive stages resulting in a lot of modification and rework.
5. Requirement management is the process of analysing, documenting, tracking, prioritizing and agreeing on the requirement and controlling the communication to relevant stakeholders.
Software requirement can be of 3 types:
1 Functional requirement
2 Non-functional requirements
3 Domain requirements
4.2.1 Functional Requirements:
1. These are the requirements that the end user specifically demands as basic facilities that the system should offer.
2. All these functionalities need to be necessarily incorporated into the system as a part of the contract.
3. These are represented or stated in the form of input to be given to the system, the operation performed and the output expected.
4. They are basically the requirements stated by the user which one can see directly in the final product, unlike the non-functional requirements.
4.2.2 Non-functional requirements:
1. These are basically the quality constraints that the system must satisfy according to the project contract.
2. The priority or extent to which these factors are implemented varies from one project to other. They are also called non-behavioural requirements.
3. They basically deal with issues like:
a) Portability
b) Security
c) Maintainability
d) Reliability
e) Scalability
f) Performance
g) Reusability
h) Flexibility
4. NFR’s are classified into following types:
a) Interface constraints
b) Performance constraints: response time, security, storage space, etc.
c) Operating constraints
d) Life cycle constraints: maintainability, portability, etc.
e) 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.
4.2.3 Domain requirements
1. Domain requirements are the requirements which are characteristic of a particular category or domain of projects.
2. The basic functions that a system of a specific domain must necessarily exhibit come under this category.
3. 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.
4. These requirements are therefore identified from that domain model and are not user specific.
Key takeaways:
1. These are the requirements that the end user specifically demands as basic facilities that the system should offer.
2. The priority or extent to which these factors are implemented varies from one project to other. They are also called non-behavioural requirements.
3. 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
4. The basic functions that a system of a specific domain must necessarily exhibit come under this category.
1. Quality of service (QoS) requirements specify how well a functional requirement shall be accomplished.
2. In real-time and embedded systems, QoS requirements may specify properties of the system (for example, range, speed, throughput, capacity, reliability, maintainability, evolvability, time to market, safety, predictability, schedulability), or properties of the process.
3. As a rule of thumb, if it's something that can be quantified or optimized, then it is a QoS requirement. For example (QoS requirements italicized):
a) The angle of the telescope shall be set in units of 0.1 degrees with a maximum error of 0.01 degrees.
b) The aesthetic agent shall be controllable from 0.00% to 5.00% by volume in units of 0.01% with an accuracy of 0.005%.
c) Locking clamps shall engage in the event of an elevator support cable breakage within less than 0.5 seconds.
d) The device shall alarm within 10 seconds if the heart rate falls below 30 beats per minute.
4. The defining characteristic of real-time systems is the level to which QoS timing requirements figure into the correctness of the system.
5. In non-real-time systems, late is acceptable. In real-time systems, late is unacceptable. Put another way, a real-time system is not necessarily fast, but it is predictably timely.
6. Of course, real-time systems may be hard real-time, which means that responses to events for aperiodic systems or actions taken when a periodic task begins (time-driven systems) must complete by a specified deadline.
7. Systems may also be soft real-time. For example:
a) Event responses shall be handled on average within a certain time.
b) A certain number of event responses shall be handled within a specified timeframe.
c) A specified failure rate is permitted.
Key takeaways:
1. Quality of service (QoS) requirements specify how well a functional requirement shall be accomplished.
2. As a rule of thumb, if it's something that can be quantified or optimized, then it is a QoS requirement. For example (QoS requirements italicized):
3. The aesthetic agent shall be controllable from 0.00% to 5.00% by volume in units of 0.01% with an accuracy of 0.005%.
4. Event responses shall be handled on average within a certain time.
1. Formal methods are system design techniques that use rigorously specified mathematical models to build software and hardware systems.
2. In contrast to other design systems, formal methods use mathematical proof as a complement to system testing in order to ensure correct behaviour.
3. As systems become more complicated, and safety becomes a more important issue, the formal approach to system design offers another level of insurance.
4. Formal methods differ from other design systems through the use of formal verification schemes, the basic principles of the system must be proven correct before they are accepted .
5. Traditional system design has used extensive testing to verify behavior, but testing is capable of only finite conclusions.
6. Dijkstra and others have demonstrated that tests can only show the situations where a system won't fail, but cannot say anything about the behavior of the system outside of the testing scenarios In contrast, once a theorem is proven true it remains true.
7. Roughly speaking, formal design can be seen as a three step process, following the outline given here:
a) Formal Specification: During the formal specification phase, the engineer rigorously defines a system using a modeling language. Modelling languages are fixed grammars which allow users to model complex structures out of predefined types. This process of formal specification is similar to the process of converting a word problem into algebraic notation.
b) Verification: As stated above, formal methods differ from other specification systems by their heavy emphasis on provability and correctness. By building a system using a formal specification, the designer is actually developing a set of theorems about his system. By proving these theorems correct, the formal.
c) Implementation: Once the model has been specified and verified, it is implemented by converting the specification into code. As the difference between software and hardware design grows narrower, formal methods for developing embedded systems have been developed. LARCH, for example, has a VHDL implementation. Similarly, hardware systems such as the VIPER and AAMP5 processors have been developed using formal approaches.
Key takeaways:
1. Formal methods are system design techniques that use rigorously specified mathematical models to build software and hardware systems.
2. Formal methods differ from other design systems through the use of formal verification schemes, the basic principles of the system must be proven correct before they are accepted.
3. This process of formal specification is similar to the process of converting a word problem into algebraic notation.
4. As the difference between software and hardware design grows narrower, formal methods for developing embedded systems have been developed.
1. Structured Analysis and Structured Design (SA/SD) is diagrammatic notation which is design to help people understand the system.
2. The basic goal of SA/SD is to improve quality and reduce the risk of System failure. It establishes concrete management specification and documentation. It focuses on solidity, pliability and maintainability of system.
3. Basically the approach of SA/SD is based on the Data Flow Diagram. It is easy to understand SA/SD but it focuses on well defined system boundary whereas JSD approach is too complex and does not have any graphical representation.
4. SA/SD is combined known as SAD and it mainly focuses on following 3 points:
a) System
b) Process
c) Technology
5. SA/SD involves 2 phases:
1) Analysis Phase: It uses Data Flow Diagram, Data Dictionary, State Transition diagram and ER diagram.
2) Design Phase: It uses Structure Chart and Pseudo Code.
- Data Flow Diagram:
1. In the data flow diagram model describe how the data flows through the system. We can incorporate the Boolean operators and & or to link data flows when more than one data flow may be input or output from a process.
For example, if we have to choose between two paths of a process we can add an operator or and if two data flows are necessary for a process we can add and operator. The input of the process “check-order” needs the credit information and order information whereas the output of the process would be a cash-order or a good-credit-order.
B. Data Dictionary:
1. The content that are not described in the DFD are described in data dictionary. It defines the data store and relevant meaning.
2. A physical data dictionary for data elements which flow between processes, between entities, and between processes and entities may be included. This would also include descriptions of data elements that flow external to the data stores.
3. A logical data dictionary may also be included for each such data element. All system names, whether they are names of entities, types, relations, attributes or services, should be entered in the dictionary.
C. State Transition Diagram:
1. State transition diagram is similar to dynamic model. It specifies how much time function will take to execute and data access triggered by events.
2. It also describes all of the states that an object can have, the events under which an object changes state, the conditions that must be fulfilled before the transition will occur and the activities undertaken during the life of an object.
D. ER Diagram:
1. ER diagram specifies the relationship between data store. It is basically used in database design. It basically describes the relationship between different entities.
2) Design Phase:
Design Phase involves structure chart and pseudo code.
a) Structure Chart:
1. It is created by the data flow diagram. Structure Chart specifies how DFS’s processes are grouped into task and allocate to CPU.
2. The structured chart does not show the working and internal structure of the processes or modules, and does not show the relationship between data or data-flows.
3. Similar to other SASD tools, it is time and cost independent and there is no error-checking technique associated with this tool.
4. The modules of a structured chart are arranged arbitrarily and any process from a DFD can be chosen as the central transform depending on the analysts’ own perception.
6. The structured chart is difficult to amend, verify, maintain, and check for completeness and consistency.
b) Pseudo Code:
It is actual implementation of system. It is an informal way of programming which doesn’t require any specific programming language or technology.
Key takeaways:
1. Structured Analysis and Structured Design (SA/SD) is diagrammatic notation which is design to help people understand the system.
2. It is easy to understand SA/SD but it focuses on well-defined system boundary whereas JSD approach is too complex and does not have any graphical representation.
3. In the data flow diagram model describe how the data flows through the system.
4. A physical data dictionary for data elements which flow between processes, between entities, and between processes and entities may be included.
5. It also describes all of the states that an object can have, the events under which an object changes state, the conditions that must be fulfilled before the transition will occur and the activities undertaken during the life of an object.
6. Similar to other SASD tools, it is time and cost independent and there is no error-checking technique associated with this tool.
7. It is actual implementation of system. It is an informal way of programming which doesn’t require any specific programming language or technology
4.6.1 Unified modelling language
1. UML is a standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems.
2. UML was created by the Object Management Group (OMG) and UML 1.0 specification draft was proposed to the OMG in January 1997.
3. OMG is continuously making efforts to create a truly industry standard.
a) UML stands for Unified Modelling Language.
b) UML is different from the other common programming languages such as C++, Java, COBOL, etc.
c) UML is a pictorial language used to make software blueprints.
d) UML can be described as a general purpose visual modeling language to visualize, specify, construct, and document software system.
e) Although UML is generally used to model software systems, it is not limited within this boundary. It is also used to model non-software systems as well. For example, the process flow in a manufacturing unit, etc.
4. UML is not a programming language but tools can be used to generate code in various languages using UML diagrams. UML has a direct relation with object oriented analysis and design. After some standardization, UML has become an OMG standard.
4.6.2 Object-Oriented Concepts
1. UML can be described as the successor of object-oriented (OO) analysis and design.
2. An object contains both data and methods that control the data. The data represents the state of the object. A class describes an object and they also form a hierarchy to model the real-world system.
3. The hierarchy is represented as inheritance and the classes can also be associated in different ways as per the requirement.
4. Objects are the real-world entities that exist around us and the basic concepts such as abstraction, encapsulation, inheritance, and polymorphism all can be represented using UML.
5. UML is powerful enough to represent all the concepts that exist in object-oriented analysis and design. UML diagrams are representation of object-oriented concepts only. Thus, before learning UML, it becomes important to understand OO concept in detail.
Following are some fundamental concepts of the object-oriented world −
a) Objects − Objects represent an entity and the basic building block.
b) Class − Class is the blue print of an object.
c) Abstraction − Abstraction represents the behavior of an real world entity.
d) Encapsulation − Encapsulation is the mechanism of binding the data together and hiding them from the outside world.
e) Inheritance − Inheritance is the mechanism of making new classes from existing ones.
f) Polymorphism − It defines the mechanism to exists in different forms.
6. OO Analysis and Design OO can be defined as an investigation and to be more specific, it is the investigation of objects. Design means collaboration of identified objects.
7. Thus, it is important to understand the OO analysis and design concepts. The most important purpose of OO analysis is to identify objects of a system to be designed.
8. This analysis is also done for an existing system. Now an efficient analysis is only possible when we are able to start thinking in a way where objects can be identified. After identifying the objects, their relationships are identified and finally the design is produced.
The purpose of OO analysis and design can described as –
a) Identifying the objects of a system.
b) Identifying their relationships.
c) Making a design, which can be converted to executable using OO languages?
There are three basic steps where the OO concepts are applied and implemented. The steps can be defined as
OO Analysis → OO Design → OO implementation using OO languages
The above three points can be described in detail as −
9. During OO analysis, the most important purpose is to identify objects and describe them in a proper way. If these objects are identified efficiently, then the next job of design is easy.
10. The objects should be identified with responsibilities. Responsibilities are the functions performed by the object. Each and every object has some type of responsibilities to be performed. When these responsibilities are collaborated, the purpose of the system is fulfilled.
11. The second phase is OO design. During this phase, emphasis is placed on the requirements and their fulfilment. In this stage, the objects are collaborated according to their intended association. After the association is complete, the design is also complete.
12. The third phase is OO implementation. In this phase, the design is implemented using OO languages such as Java, C++, etc.
13. Role of UML in OO Design
UML is a modeling language used to model software and non-software systems. Although UML is used for non-software systems, the emphasis is on modeling OO software applications. Most of the UML diagrams discussed so far are used to model different aspects such as static, dynamic, etc. Now whatever be the aspect, the artifacts are nothing but objects.
Key takeaways:
1. UML is a standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems.
2. UML can be described as a general purpose visual modeling language to visualize, specify, construct, and document software system.
3. An object contains both data and methods that control the data. The data represents the state of the object. A class describes an object and they also form a hierarchy to model the real-world system.
4. OO Analysis and Design OO can be defined as an investigation and to be more specific, it is the investigation of objects. Design means collaboration of identified objects
5. During OO analysis, the most important purpose is to identify objects and describe them in a proper way. If these objects are identified efficiently, then the next job of design is easy.
6. UML is a modeling language used to model software and non-software systems. Although UML is used for non-software systems, the emphasis is on modeling OO software applications.
1. Documentation ensures that the software development team or other stakeholders are on the same page regarding what needs to be built and are fully aware of the goal, scope, functional requirements, challenges, and budget regarding the software.
2. However, as much as creating software is exciting, documenting its requirements can be boring and tiresome.
3. A software requirements document (also known as software requirements specifications) is a document that describes the intended use-case, features, and challenges of a software application.
4. These documents are created before the project has started development in order to get every stakeholder on the same page regarding the software’s functionality.
5. Software requirements are written up by the tech team depending on the project they are working on. As non-technical colleagues, clients, and partners get involved it’s important to ensure that everyone is on the same page and agree with the scope, budget, and goal of the project.
6. Software requirement documents provide an important map of the product being built, the features that will be included, and much more.
7. This roadmap helps to keep the technical and non-technical team on the same wavelength as to what the expectations are. It helps to ensure that the product is built meeting the needs whether it’s for internal purposes, for users or clients.
Key takeaways:
1. Documentation ensures that the software development team or other stakeholders are on the same page regarding what needs to be built and are fully aware of the goal, scope, functional requirements, challenges, and budget regarding the software.
2. These documents are created before the project has started development in order to get every stakeholder on the same page regarding the software’s functionality.
3. It helps to ensure that the product is built meeting the needs whether it’s for internal purposes, for users or clients.
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 all stakeholders (business, users) needs.
A typical SRS includes:
1. A purpose
2. An overall description
3. Specific requirements
Your first step is to create an outline for your software requirements specification. This may be something you create yourself. Or you may use an existing SRS template.
If you’re creating this yourself, here’s what your outline might look like:
1. Start with a Purpose
The introduction to your SRS is very important. It sets the expectation for the product you’re building.
So, start by defining the purpose of your product.
2. Give an Overview of What You’ll Build
a) Your next step is to give a description of what you’re going to build. Is it an update to an existing product? Is it a new product? Is it an add-on to a product you’ve already created?
b) These are important to describe upfront, so everyone knows what you’re building.
You should also describe why you’re building it and who it’s for. User Needs and Assumptions and Dependencies
3. Detail Your Specific Requirements
The next section is key for your development team. This is where you detail the specific requirements for building your product.
a) Functional Requirements
Functional requirements are essential to building your product.
If you’re developing a medical device, these requirements may include infusion and battery. And within these functional requirements, you may have a subset of risks and requirements.
b) External Interface Requirements
External interface requirements are types of functional requirements. They’re important for embedded systems. And they outline how your product will interface with other components.
There are several types of interfaces you may have requirements for, including:
1) User
2) Hardware
3) Software
4) Communications
4. System Features
System features are types of functional requirements. These are features that are required in order for a system to function
Key takeaways:
1. A software requirements specification (SRS) is a document that describes what the software will do and how it will be expected to perform.
2. Your first step is to create an outline for your software requirements specification.
3. The introduction to your SRS is very important. It sets the expectation for the product you’re building.
4. You should also describe why you’re building it and who it’s for.
5. If you’re developing a medical device, these requirements may include infusion and battery
6. External interface requirements are types of functional requirements. They’re important for embedded systems
4.9.1 Requirements Validation
1. It’s a process of ensuring the specified requirements meet the customer needs. It’s concerned with finding problems with the requirements.
2. These problems can lead to extensive rework costs when these they are discovered in the later stages, or after the system is in service.
3. The cost of fixing a requirements problem by making a system change is usually much greater than repairing design or code errors. Because a change to the requirements usually means the design and implementation must also be changed, and re-tested.
4. During the requirements validation process, different types of checks should be carried out on the requirements. These checks include:
a) Validity checks: The functions proposed by stakeholders should be aligned with what the system needs to perform. You may find later that there are additional or different functions are required instead.
b) Consistency checks: Requirements in the document shouldn’t conflict or different description of the same function
c) Completeness checks: The document should include all the requirements and constrains.
d) Realism checks: Ensure the requirements can actually be implemented using the knowledge of existing technology, the budget, schedule, etc.
5. Verifiability: Requirements should be written so that they can be tested. This means you should be able to write a set of tests that demonstrate that the system meets the specified requirements.
6. There are some techniques you can use to validate the requirements, and you may use one or more of them together, depending on your needs.
4.9.2 Requirements Reviews
1. A team of system customer; those who interact with the customer to gather requirements, and system developers start reading the requirements in the document, and investigate in a great detail to check for errors, inconsistency, conflicts, and any ambiguity.
2. Then they may negotiate with the customer on how to solve the problems and errors found.
3. Prototyping
a) We’ve discussed the prototyping as one of the (non-standalone) software process methodology, which used as part of a full methodologies, and we’ve also mentioned in can be used in the requirements engineering.
b) In this approach to validation, an executable model of the system is demonstrated to the customer and end users to validate, and ensure if it meets their needs.
c) Prototyping is usually used when the requirements aren’t clear. So, we make a quick design of the system to validate the requirements. If it fails, we then refine it, and check again, until it meets the customer needs.
d) This definitely will decrease the cost as a result of having a clear, understandable, consistent requirements.
Key takeaways:
1. It’s a process of ensuring the specified requirements meet the customer needs
2. These problems can lead to extensive rework costs when these they are discovered in the later stages, or after the system is in service
3. Verifiability: Requirements should be written so that they can be tested. This means you should be able to write a set of tests that demonstrate that the system meets the specified requirements.
4. A team of system customer; those who interact with the customer to gather requirements, and system developers start reading the requirements in the document, and investigate in a great detail to check for errors, inconsistency, conflicts, and any ambiguity.
5. This definitely will decrease the cost as a result of having clear, understandable, consistent requirements.
References:
- Real- Time Systems Design and Analysis.. Tools for the Practitioner by Phillip A Laplante, Seppo J.Ovaska ,Wiley - 4th Edition
- Embedded Real Time Systems: Concepts, Design and Programming - Dr. K.V.K. Prasad -Black Book, Edition: 2014
- Real Time Systems Theory and Practice , Rajib Mall , Pearson Education
