Requirements: Organization & Allocation

1. EMIS 8340 Systems Engineering Tools—applying tools to engineering systems Requirements: Organization & Allocation Mark E. Sampson

2. Requirements Organization • Once we get all of these requirements captured, how do we find the ones we are looking for? • Some stats: • chip factories have 250,000 requirements dealing with materials alone (1200 of which change on a monthly basis due to regulatory, safety, technology, policy, etc. changes) • CVN 77 aircraft carrier has 1.2 million requirements • Nuclear materials handling applications deal with ~750,000 requirements • …even 100’s of requirements can be a “needle in a haystack” • In addition: • Organization reveals omissions • Ensures no losses along the way • Standard organization scheme improves communication

3. Requirements Organization… • How to organize requirements? • Based on what you need to get out tool • Easy/consistent “filing rules” • Make it easy to find them later • Some requirements organization techniques… • Folders/directory structures • Naming conventions • Document Outlines • Attributes/Properties • Sub-typing/classifying • Linking “Radar, where do you file Jeep Maintenance records? J for Jeep or M for Maintenance? Neither. It’s under I. Why would you file it under i? I is for Iowa. We have a lot of Jeeps in Iowa. Every time I think of Iowa, I think of Jeeps.”

4. Requirements Organization: by folders • Filing system (like your directory structure on C:/) • Lots of different approaches • Need to agree as a project on your organization scheme • No data redundancy—requirement db handles that • …is it a good organization scheme? • Can you get to the thing youare looking for the same waylater? • Can others get there? • According to PDM Analysts…25% of engineers time is spent looking for the information they need.

5. Requirements Organization: by naming • Naming convention…SYS1000-32 • Prefixes/Suffixes (SYS, MOD,…) • Dewy Decimal Numbering (1000-2000 is airframe,…) • Other Group Technology schemes • Remember the PUID/ROIN/ROID (unique Requirement ID Number) [SE Handbook 8.4 ]

6. Requirements Organization: by document output • Based on document outline such as DoD or IEEE standard (Mil-Std 490, EIA632, IEEE1220, and others) • usually will require some tailoring to meet your specific needs • danger of spending more time working on document template than doing the job • Start at high level, use your operational concept or functional breakdown or other obvious system organization • make sure the format of the document doesn’t dictate system partitioning/organization • make sure your numbering doesn’t get out of hand 3.1.2.4.5.1.2 • does it make sense from a developers perspective? [Hooks 2001] [SE Handbook 8.4 ]

7. Requirements Organization: by attributes/property • Property/Attribute values (phase, status, due date, subsystem,…) • Lots of different approaches • Need to agree as a project on properties and choice list • Properties come in several flavors: • Single & multiple choices • Fill in text • Numbers • Date • Boolean (true/false, yes/no)

8. Requirements Organization: by sub-type • Sub-type/Classification (test, safety, regulatory, derived, performance, customer,…) • Lots of different approaches • Need to agree as a project on sub-types and control them (CCB) • Sub-types typically inherit the properties of their parents, but can have their own property set

9. What System Architect How Sub-system Sub-System Sub-System HW SW Test Component Component • Requirements Allocation • A discussion on system/requirement levels… • Requirements at one level, become the “what it needs to do” for the next level down. • These levels go by a variety of names…system, sub-system, segment, element, block, unit, … • How many levels depends on system complexity • Higher level requirement should not dictate a solution for their “child” requirements • Try not to mix levels, sincethey represents partition boundaries… [SE Handbook 8.4 ] [Hooks 2001]

10. What System Architect How Sub-system Sub-System Sub-System HW SW Test Component Component • Requirements Allocation..what is it • The process of assigning each system level requirement to the component(s) that accomplish the requirement…and repeat down the hierarchy as needed • Start at the top & work your way down • With each “level” specialist doing the allocation • Saves time • Prevents mis-interpretation • Makes sure all requirementshave been addressed • Provides impact understanding • Provide communication medium [SE Handbook 8.4 ] [Hooks 2001]

11. Requirements Traceability..what is it • Allocated requirements are analyzed, etc. during the process of design, creating new requirements to be allocated, etc. Looking back up this allocation chain is traceability. • Does every requirement have a pedigree, otherwise it’s an orphan…orphans mean creep, hidden change, gold plating,… • Do it as you make decisions • Keeps from over/under doing it • Decreases risk, change,… • Gives system-level view to understand change impact • Prevents mis-interpretation • Makes sure all requirementshave been addressed • Provides impact understanding • Communication medium What System Architect How Sub-system Sub-System Sub-System HW SW Test Component Component [SE Handbook 8.4 ] [Hooks 2001]

12. Requirements Allocation/Tracing…the process • Define top-level requirements • Design/Architect product (what if…) • Allocate top-level to second-level sub-systems • Derive next level requirements • Repeat as needed… • Tools automate this process… • Some RM tools take a document centric approach…Calibre, DOORs, Contour, Reqtify, etc. • Where a document outline represents the product decomposition • Benefit: interact with a document Downside: it’s only a document • Some SE tools use a design centric approach…TcSE, CORE,... • Where document is an output from structures & relationships • Benefit: interact with a model Downside: it doesn’t look like a document [Hooks 2001] [SE Handbook 8.4 ]

13. Standard Desktop Tools …according to a time & motion study by TI, Systems Engineers spend 50% of their time writing documents, 25% of their time re-entering the same information in different locations, 14% of their time futzing (technical term for getting documents to print correctly), and 30% of their time in meetings,… …you’ll notice it adds up to greater than 100% due to average SE workweek of 60+ hours One of the fundamental purposes of Tools is to accelerate your job. [Sampson 1994]

14. DESIGNSPEC. Why documents… Given the amount of time spent on documents, it’s easy to get confused about what the systems engineering product is… …a document? Or a design? A discussion about wheelbarrows.

15. DESIGNSPEC. DESIGNSPEC. DESIGNSPEC. • Documents…a means of conveying design decisions • Tools are used to accelerate the capture and delivery of design information. Documents are one way to do that. • Upside of documents: • Codify the design • Communication • Culturally acceptable • How you get paid • The downside of documents: • Paper based baselines & management systems • Nobody reads them • Obsolete by the time you print them • Give you a good feeling about project if documents are on schedule

16. Requirements Documentation • A means of delivering requirements/design… • Best: Deliver from online, trusted source • Traditional: Deliver in document form • Remember the message is what is important, not the messenger • Document organization is not system architecture • Documents have a life of their own…$20/page/year in classified programs I make it a habit of asking organizations that I visit— “Do you trust your requirements/design documentation to be an accurate representationof the current state of design”? Usually without hesitation, I get “of course not” answers. The design changes faster than the documentation. In fact, one of the rites of passagefor “green” engineers is a final revisit of the spec’s to update them to match the design asa training exercise. Which begs the question, if the spec’s are so worthless, why do we spend up to 50% of our time messing around with documents.

17. Mod-Spec. Mod-Spec. Sub-Spec. Sub-Spec. SystemSpec. Mod-Spec. Sub-Spec. • Requirements Documentation—Spec Trees • Document(s) that is/are organized around some system decomposition. • How many documents? • Depends on complexity—could be one, could be several • Spec’s reference each other—make it easy to follow the chain • Remember to partition the documents to make it easy to deal with change • Outsourced components deserve their own spec. System Architect Sub-system Sub-System Sub-System HW SW Test Component Component [Hooks 2001] [SE Handbook 8.5 ]

18. Mod-Spec. Mod-Spec. Sub-Spec. Sub-Spec. Sub-Spec. SystemSpec. Mod-Spec. • Requirements Documentation—web-based documents • Documents are organized around system decomposition, posted, and delivered online (web,, etc.) • Documents still need to be created/posted, only delivered via web rather than in printed form (typically html, pdf, or gif/jpg images • …example/demo of an online document repository. System Architect Sub-system Sub-System Sub-System HW SW Test Component Component

19. Requirements Documentation—online requirements database • Requirements are created, organized, and maintained in an online database. • Requirements are delivered directly to users via web, query, etc. from the database rather than translating into some other form for delivery System Architect Sub-system Sub-System Sub-System HW SW Test …in class demonstration Component Component

20. LEAN thinking in requirements... • LEAN…all about removing waste…including requirements… • Overproduction: to produce more than demanded or produce it before it is needed. It is visible as storage of material—i.e. working/managing requirements via documents. • Inventory or Work In Process (WIP): is material between operations due to large lot production or processes with long cycle times—i.e. waiting for document approvals, review cycles, etc. • Transportation--i.e. transporting documents • Processing waste: asking why a specific processing step is needed and why a specific product is produced. All unnecessary processing steps should be eliminated—i.e. why documents, why approvals, why storage,… • Motion: of the workers, machines, and transport • Waiting: for a machine to process should be eliminated—i.e. why requirement has to wait until a document is complete before routing/approvals. • Making defective products: is pure waste—i.e. the point of requirements “No greater waste than doing something efficiently that shouldn’t be done at all.” [isixsigma institute, advancedmanufacturing.com]