Design for Electrical and Computer Engineers Fall 2019

  • Slides: 20
Download presentation
Design for Electrical and Computer Engineers Fall 2019 Chapter 3 Dr. Seval Ören Eskisehir

Design for Electrical and Computer Engineers Fall 2019 Chapter 3 Dr. Seval Ören Eskisehir Technical University

Chapter 3: The Requirements Specification

Chapter 3: The Requirements Specification

3. 1 Overview of the Requirement Setting Process Specification (n): A detailed and exact

3. 1 Overview of the Requirement Setting Process Specification (n): A detailed and exact statement of particulars, a statement fully describing something to be built. - American Heritage Dictionary The Requirements specification: § Should identify all important requirements while providing enough flexibility for the design team to develop innovative solutions. § Serves as a communication tool for everyone involved in the design, such as engineering, marketing, and the client. § Should have all parties agree to the requirements before further development proceeds. § Serves as a legally binding agreement between the developers an the client in some cases.

3. 1 Overview of the Requirement Setting Process Customer : Marketing requirements. Design of

3. 1 Overview of the Requirement Setting Process Customer : Marketing requirements. Design of Electrical and Computer Engineers, Mc. Graw Hill, Ralph Ford and Chris Coulston, Copyright 2008. Environment: Requirements in the form of constraints and standards that impact or limit the design. Technical Community: The knowledge of engineers who are primarily responsible for design, implementation, testing, manufacturing, and maintenance.

3. 2 Engineering Requirements Ø Engineering requirements are short statements that address a technical

3. 2 Engineering Requirements Ø Engineering requirements are short statements that address a technical need of the design. A simple example is: "The system should be able to supply 50 watts of power. " 5

3. 2. 1 Properties of Engineering Requirements I. Abstract § Specifies what system will

3. 2. 1 Properties of Engineering Requirements I. Abstract § Specifies what system will do, but not how it will be implemented. § Unless necessary, the requirements should say nothing about the implementation. II. Verifiable § There should be a way to measure or demonstrate that the requirement is met in the final system realization. § This property is used to answer the question of “Are we building the system correctly? ”. 6

3. 2. 1 Properties of Engineering Requirements III. Unambiguous § Each requirement should have

3. 2. 1 Properties of Engineering Requirements III. Unambiguous § Each requirement should have a single unambiguous meaning. § Should be stated with short complete sentences. IV. Traceable § Requirements should be traceable marketing requirements. § If the design does not satisfy the customer needs, it won’t be successful. 7

3. 2. 1 Example §A robot whose objective is to navigate autonomously within a

3. 2. 1 Example §A robot whose objective is to navigate autonomously within a specified environment. §Requirement: §The robot must have an average forward speed of 0. 5 feet/second, a top speed of at least 1 foot/second, and the ability to accelerate from standstill to the average speed in under 1 second. §Are the four properties for an engineering requirement met? §Abstractness: § Unambiguousness: YES §Verifiability: § Traceability: 8 YES NO

3. 2. 2 Fifth Property - Realism § This is not defined in the

3. 2. 2 Fifth Property - Realism § This is not defined in the IEEE standard as a property, but it is an important aspect. § The requirements for the project must be realistic. § To be realistic, there should be a way of demonstrating that the target is technically feasible. § For example, a requirement could indicate that a robot should travel at a speed of 1. 000 mph, which could be abstract, verifiable, unambiguous, but completely unachievable. 9

3. 2. 3 Constraints § Constraint : A design decision imposed by the environment

3. 2. 3 Constraints § Constraint : A design decision imposed by the environment or an input that impacts or limits the design. § In design, a constraint is a special type of requirement. § Constraint requirements often violate the abstractness property. 10

3. 2. 3 Constraints - Example A constraint requirement : The system must use

3. 2. 3 Constraints - Example A constraint requirement : The system must use a PIC 18 F 52™ microcontroller to implement processing functions. § This constraint requirement specifies how the system will be implemented. § This could be because the project sponsor has developed a high level of expertise or has made a great deal on this component. § Or the company does not want to spend the development time learning a new platform. § If there is any constraint in your project, it has to be 11

3. 2. 4 Standards §A standard is an established way of doing things that

3. 2. 4 Standards §A standard is an established way of doing things that ensure interoperability. §Standards ensure that products work together, therefore use of technology would be severly limited without them. § Example: If each manufacturer uses its own communication protocol instead of RS-232 or USB, it would be hard to print, connect to server, etc. §Furthermore, standards ensure the health and safety of products that we use every day. 12

3. 2. 4 Standards What standards are relevant to your project and how do

3. 2. 4 Standards What standards are relevant to your project and how do you use them? § Different levels of usage § User § Implementation § Developer § Types of standards § Safety, testing, reliability, communication, data format, documentation, connector standards, metastandards, etc. 13

3. 2. 4 Standards User Level: § At this level the standards are simply

3. 2. 4 Standards User Level: § At this level the standards are simply employed in the design. § Detailed technical knowledge of the standard is typically not necessary. Example: When a component communicates to other devices, it is a standard communication protocol is used. Detailed knowledge of the standard isn't required except configuring software or hardware to 14 communicate with.

3. 2. 4 Standards Implementation Level: § Details of the standard need to be

3. 2. 4 Standards Implementation Level: § Details of the standard need to be understood in this level. § Standards are most likely to impact the design and requirements. Example: To develop low-level drivers for a computer, you need to become an expert on the underlying standard. 15

3. 2. 4 Standards Development Level: § In development level, new standards are constantly

3. 2. 4 Standards Development Level: § In development level, new standards are constantly being developed and existing ones are modified. § Depending upon the standard, engineers from different organizations, professional societies, and corporations take part in the standards setting process. 16

3. 2. 4 Standards Development Level: § It can be difficult to navigate the

3. 2. 4 Standards Development Level: § It can be difficult to navigate the world of standards; they tend to be highly detailed and limited parts of a standard may to apply to a project. § In addition, many standards are costly to obtain, while some are freely distributed. 17

3. 2. 4 Standards Development Level: § Advice to identify and employ standards: I.

3. 2. 4 Standards Development Level: § Advice to identify and employ standards: I. Conduct research on applicable standards (websites of standard organizations, IEEE Xplore database). II. Determine the exact level of interaction. Try to foresee whether you need to apply standard. III. Ask your client. They may have their own internal standards, procedures or experts on applicable standards. 18

3. 2. 4 Standards Some Types of Standards: Safety: How to design and test

3. 2. 4 Standards Some Types of Standards: Safety: How to design and test products to ensure that they are safe. Testing: Often related to safety, but are broader in scope. Standardized benchmark tests are used for comparing computational performance, such as SPEC. Reliability: Address general reliability principles and design methods for different electrical systems, such as IEEE and military standards. 19

3. 2. 4 Standards Some Types of Standards: Documentation: Technical report documentation, such as

3. 2. 4 Standards Some Types of Standards: Documentation: Technical report documentation, such as ISO 9000. Connector Standards: Standards for cable connections are common and should be followed to ensure systems are interfaced. Metastandards: A combination of multiple standards. For example, the RS-232 standard is a combination of a mechanical standard describing the connector physical dimensions, an electrical standard describing the voltages, a functional standard describing the pins and their function. 20