Modeling Requirements Narrated2


Published on

Finally requirements that work! Using new standards we can now model requirements directly in a UML tool. The presentation covers the new SysML standard and how it adds requirements to modeling and how this can reduce errors and increase productivity for both systems engineering and software development.

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • In this session you will learn how requirements modeling from Systems Engineering has been mixed with UML and how this can greatly ease the creation and tracking of requirements. Finally project requirements are no longer a big document that you use to prop your door open or keep handy in the winter for kindling. Requirements become living entities connected throughout your design and code.  Developers can see and show what they have done and not done. It is also simple to do cost and risk analysis without paying for costly tools. This is not tool specific, just a set of techniques that can be implemented with any modern UML tool.
  • I’ve already mentioned that people are a root of the problem. Let’s look at how they create that mess.
  • The problem however is that a clear set of understandable and testable requirements give you a lot of benefits.To be clear, bad requirements cause the reverse of the benefits.
  • I also want to quickly cover this subject in terms of Agile. If you don’t mention Agile or the other buzzword, SOA, nobody will come to your talk. But we do need to be clear about how Agile fits with both modeling and requirements.One of the great myths of Agile is that it does away with requirements. There may be a few crazies out there that go to that extreme, but that is not the wide view. It is also something that can’t simply be thrown away depending on the industry or corporate rules. What Agile does do is like many other methodologies, reduce requirements to those that are the most useful. Agile also tries to focus on functional and testable requirements but does not loose non-functional requirements and places special emphasis on performance.Agile is also different from many methodologies because it allow requirements to be living rather than static. If you have iterative development you need to change priorities of what requirements to support and we also know full well that ‘some’ requirements change during the lifetime of an application.SysML requirements fall into the Agile process rather cleanly. There are a few things you want to do to aid iterations like extending to add data for sorting and estimating, but it is rather simple to do. Modeling is still a bit of a sore subject with Agile folks. A key reason is that they spend vast sums of money on IBM tools and training per developer and call that a waste because you don’t get what the salesman said you were going to get. We believe firmly that tools matter in Agile, it is all a matter of how deep you go and the value you can get from your tools. The only thing I want to say is that it is how you use your tool and the value you get. If you don’t concentrate on your tool, you will get no value. We preach understanding and we try to pull as much value as we can. Requirements modeling is just one more way of doing this.Reference:Agile and Iterative Development: A Manager's Guide
  • This is another way to look at the Agile verses the Modeling fight.
  • Now we need to understand an implementation of requirements in UML. I am using the SysML profile which contains a requirements metamodel. Oddly it took system engineers to come up with this. For some reason software developers did not think this way. However it is wickedly obvious. When I first saw this I almost got a concussion from that “I could have had a V-8” slap to the head.The primary reason for their thinking this way is that in aerospace they still base everything on requirements. The people involved involved in creating the spec with big contracts with complex systems with many lives depending on their success. You are really careful when launching a rocket, flying a plane of people, or dropping a bomb.The creators were also hardware oriented. They think in terms of parts and systems made of parts. This is another reason why the idea works well as it relates well to the real world.
  • UPDM as an extension of UML is nothing more than semantic tagging (vocabulary) and rules about our grammar.From a dictionary you can write all the world books. With UPDM you can describe any enterprise.I don’t want you to think there is a mystery here. This isn’t ontology or the semantic web. This is similar, but simpler.With UML we also have visualization of the grammar. This is highly important, because we need to communicate.
  • The goal for SysML was to create a model of systems and have traceability to its requirements. The simplest way to meet this goal was to also model the requirements themselves. Once you start thinking this way, a lot of things become obvious.I was talking with one of our competitors a while back and he was saying proudly that they have been doing this for years. Problem is that they had not taken approach that truly separated the requirement from the object of the requirement. What this meant is that you could not reuse a requirement or do other things with it. The requirement was just part of the documentation for the class or interface. SysML requirements is far more flexible and creates more usable value through the lifecycle.The picture here is part of the story. Requirements have been around for a long time, like the castle. But like really old things, they fall down – sometimes they are torn down by their enemies. This castle in Lithuania was pretty much just foundation. It was rebuilt using enough modern technique and knowhow to bring it back to its former glory. Requirements in SysML are similarly rebuilt from very old foundations but with modern techniques.
  • The core idea for modeling requirements is not just the requirement. Yes, we need to do that right, but we also want to model everything else. This drawing is missing one thing. Requirements also are related to other requirements. We refine, derive, and group requirements based on other requiremetnsts
  • The modeling of requirements has a lot of value because of the rest of the model. We can show dependencies between the requirement and other things. Look at the advantages! The last, “one source of truth” is not really obvious but is very important. Even with user stories, use cases, tests, and other data, the requirement is the key storage for truth. I don’t mean to say truth is not in those other areas. For example a refinement via a use case should be reflected back at the requirement. The key is that we have a way to correct a requirement. But as you proceed you add more and more references to a requirement. In the end we have design, implementation, tests, and the analysis linked to the appropriate requirements. You can go anywhere and find what requirement the work is related to.The web of data helps understand the impact of change, find gaps, etc. Tools are important, but we are not talking rocket science. This is just simple UML modeling. Tool makers can make this easier, but nothing prevents you from applying this quite simply.
  • Here are the artifacts we use. Note that these are just related to requirement but not all you can use. As I have said before, we can link and reference many other artifacts.Note that copy is to re-use a requirement and trace is a general concept that
  • The one thing that gives all of this power is the use of dependencies. They give you a way to generically relate things in the modelIf I then use stereotypes like satisfy and verify, I create a contract dependency.I can also manage the dependencies and watch them come and go. So if a requirement goes away, all the code/tests loose the relationship and I can choose to take that stuff out of the code.
  • Let’s start with a few of some requirements that should be true all the time. These are not requirements that are directly associated with business requirements, but are true for most applications.The big problem with business requirements analysis is that we often forget the things that are always true. Usability and data integrity are two important groups of requirements that are almost always forgotten. These things are also easily tested and reuse can be very high if you assume these things are always true, you always address them.Login is my favorite example. There are a lot of requirements. The business requirements are usually minor, consisting mainly that there is a login. What usually happens? Nobody thinks of these requirements. Login across your products don’t behave the same. There is no re-use. New bugs are created for every implementation and the login isn’t right until version 3.5 service pack 2 of your product.I often try to log into web sites and find my password does not work. Why? I use strong passwords. More than 8 characters. But I got no warning, there were no errors, and even when I typed it twice and the system will not let me continue unless the passwords match. But the system truncated to 8 and did not tell me. A simple test would have found this, but not without a requirement that says what is good and what is bad and that I test the behavior of both.It may seem like a lot of work. The reality is that if I find a standard requirement, it is linked to both the older code and older tests from prior projects that I don’t have to think about.Re-use should happen because of a cascade from your requirements. To expect re-use because you have a library is hubris. You need a reason to re-use rather than just omponents that can be re-used.
  • Looking a little closer, you can see the relationship I am using is containment. One requirements contains finer requirements. You can use a derive, but I like this because it is easier to manage. I do use a derive that you will see in a moment, but usually only when I cross domains or concepts which lead to the need of a requirement.
  • Now I am looking at the application requirements (in blue). Note that I have a lot derived from my standard requirements. Not seeing the whole set of requirements because I want to show the different points of view. It is important to understand that each of these have different points of view and different tests to confirm or can control a generic test with application specific requirements. A good example is an error dialog. We can use a lot of standard requirements for look and feel, but the reason for the error message and the message itself is specific only to the application.
  • JSP InteractionDesign
  • Use cases are nice. But what do they show? Quite simply a use case should show users and action oriented interfaces. The Use Case is great for this, but it is not the whole story. It can help validate the user interface, but that is where at lease the stops.We can go deeper into the use case descriptions, the activity, and sequence diagrams to refine further. But this is refinement of the design in many cases, not ensuring that the design meets specific requirements. Requirements are different. Different level of abstraction. Different purpose. Different usage.
  • The important thing to notice here is the text. The use case does a very specific job to describe the use. The requirement is a different twist. The blue boxed requirement is a usability requirement. The pink box is a functional requirement. The two requirements are from different points of view. You might say, well, we met one requirement, why have two? Simply, the way we would like our requirements to work is that this is partially coincidence and the other that it is confirmation of good design. In this case, the designer could leave out “cancel” login and just force the user to “Close Application”, but this would reduce usability as our other requirement shows. To reinforce the principal applied, there is a reason for that usability requirement in that it should force into existence functional requirements. This does not always happen, but the point is that it is good. But…. Why the heck can I say this? Simply this diagram mixes the requirements and use case so that I can see this.
  • So, if are assuming that we can’t rely on people successfully implementing requirements, we need a way to test. The beauty of the Agile is the test first methodology. But there is a problem. Test first concentrates mostly on code. That is fine, but it does not usually test for requirements but implementation. Nothing wrong with that, but we need to cover both implementation and compliance to requirements.
  • One of the important uses of a requirement in a model is linking the test cases. This is just following what we just did with the use cases. We get the same power. We can do this with JUnit as well as other test frameworks.Now you might say, why not trace to the use case for testing? Sure you can do that, but remember that use cases are primarily for interfaces. There are a lot of requirements that don’t have anything to do with interfaces.Looking at the authenticate via LDAP and the cancel action requirements you can see how these are not easily applied to a use case. The LDAP requirement is an interface implementation and cancel action is a requirement that comes from our usability standards which are expressed in terms of requirements.
  • We have talked about our requirements. What about the specific GUI? We can do that too. In MagicDraw this is rather simple because I have a very special GUI diagram that uses UML to design a GUI.
  • Once we have the elements, we can then attach our requirements.Here we have the cancel button and default action buttons shown.
  • Just in case, why not trace the use cases too?
  • Time to link the requirements to the implementation. This is one of our more important diagrams because it shows where we actually do the specific work.The links are called Satisfy dependencies and are drawn from the implementation to the requirement they fulfill. We can link specifically between either a package, component, class, and interface, a method, or even a class variable if we want. This should be more than enough granularity to show how a requirement is satisfied. In addition to the requirements, note the yellow boxes. These show data about the linkage between the requirement and the implementation. We additional details about the priority and the hours associated with meeting the requirements.
  • You have already seen how we associated the hours and customer priority. We can add a lot of other data or calculate metrics that help us with project planning, management, and execution. Usually this is done with stereotypes applied or dependencies drawn between artifacts, or combinations.
  • If we can see what we are doing with links between design, test, implementation, and our requirements, imagine what we can not see. If nothing links to a requirement, it is a gap. If nothing links code to a requirement, perhaps it is not meeting any requirement. Any artifact in our design that is missing an association can be suspect for either too much work or not enough.
  • In these two matrixes, we use the tool to show us one type on one axis and our requirements on another. The upper left is showing Verify relationships and on the lower right, satisfy relationships. Some have links and some do not. You could create these charts with reporting or in our case a plugin that was written to do the job. The data is in the UML model and that is what is important.
  • Here is a chart showing how we refined requirements with our use cases. Note that some use cases have more than one requirement that they satisfy.
  • What we have just shown can follow a simple process. You could choose a different process, but the steps are going to be fairly simple. If you were story driven, you might start there, move to use cases, then requirements. Or if you were test driven, you could start there. The point is however that this technique can fit within many different methodologies and give significant value.The importance of the data can also aid many methodologies by adding more data for estimates and even success of your implementation. I have seen a lot of spreadsheets in my time and this beats that by quite a margin because we manage the data in the model.
  • For the developer, the specific iterations are also fairly simple. Because design, tests, and requirements can all be managed in the model, it is easier to do iterations and manage the reporting many managers want. The side benefit is that a lot of the data is just as important to the architect and developers. In our own company we are working on ways to integrate model data with task data in systems like Jira.
  • The problem with change is staying on the road. Sure we might want to change direction, but we don’t want to do this at the expense of chaos.
  • Why modeling and requirements?
  • So, you may still not like requirements or might think that though this is cool, what else can you do?
  • First, I want to add requirements knowledge as additional documentation. Simple idea.We don’t stop there. With good Java annotation we can inject the data for logging or even specific methods to trigger monitors to ensure that code related to use cases or requirements are actually executed during tests. One cool thing to imagine is that code can log that it should be called during specific unit tests. Imagine a login test that includes in the log that the code that was executed was related to a use case, the requirement, and a specific test case. The cool thin is that you get this for free.
  • Real quick, here is an extension in UML that I have used to generate code to support Java annotations.These annotations are to specifically support requirements traceability.
  • Here are the annotations used in the code.
  • So, that is what we have for today.Requirements is still hard. We can’t deny that. But if we change the way we create, trace and use requirements, we have more knowledge, make fewer mistakes, and have better feedback.Don’t look at this as just requirements. There are simple ideas here. UML is very malleable and there is a lot of room for very pragmatic things to help you improve and be more agile.
  • Quite simply the tale here is about setting goals which guide your path. There are an innumerable number of methods. The world seems re invent and then re-invent techniques to get us from point A to B by analysis, diagram, and or process. The simple fact of the matter is that people are people. Failure can come from the creation of requirements or the interpretation and implementation of requirements. The root of all all failure is the human. Murphy just brought this to our attention by pointing to the real root of the problem: People. Think about the overbuilding of systems and the backup systems in airplanes and spacecraft. Is this for the possible failures of the equipment? No. Think about how this comes about, a human designed it and we have issues of price, performance, weight, etc. These are human set criteria that contribute to the possibility to failure.Failure is inevitable. The key then is to reduce failure and to have methods that can recover from failures or limit their affect. For requirements we want to improve understandability. On consumption we need to improve our ability to execute and to verify we are meeting requirements. Someplace in the middle, we need to choose the right requirements. So, where do you want to go?The key then is to choose a method – or two or three – that define what you want and then use a technique that helps prove that you are getting what you want. The technique here will focus on everyday requirements that are modeled rather than just text. The tool is UML based and there are many tools like it. No Magic’s tool is better of course! We also believe in this technique, so we are probably better than the other guys, but everything you will see is at least possible using current UML standards.
  • ROI Return on Idea Return on Information Return on Investmernt
  • The problem with negative thinking is that it pays off. This is especially true for software projects where the odds of failure are pretty good and negative thinking contributes greatly to errors.Just the act of being negative or contributing negative argument can suck the life out of any Endeavour because the human brain is a bit lazy. The brain is easily swayed by negativity. The brain seems to be wired to filter ideas based on negative attributes. The only time this is not true is when the reward is great. Take lotto tickets. If you can say there is a great reward, the brain gets all googaly. But look at the cost for a lotto ticket. Pretty easy to delude yourself. Other forms of gambling are similar. You usually don’t loose all your money at once, so it is hard for the brain to figure out what is wrong. Negative thinking is just another type of gambling. It does not cost a lot to poke holes in something. Reward is quick too. Most negative comments have no logic to argue against other than the fact that it is a bad argument, so you will usually win unless you are arguing against a true critical thinker. Worse the person arguing in a negative way is not swayed by logic…. How do you think they came up with the negative argument?
  • One of the great motivators, or rather de-motivators is fear. Fear is subtle. Fear can cause avoidance or action. For example, people that fear pain will avoid things that cause pain. However, people that fear the possibility of pain will often do so without regards to the odds of the pain event or even the scale of pain. Many fear the injection of a needle. The fear is very real, but the pain is often minor and very quick. The fear of pain though could cause you to miss an inoculation or cause worse pain because of a fear of the needle at the dentist. The fact is, as humans we easily go the wrong way on a risk benefit analysis – especially when we don’t closely examine the facts. We get the same problem with methods in software development. Best book on software I have ever read was “The Inmates Are In Charge of the Asylum” by Cooper. It is not a great book, but the insights Cooper had on why software is so bad was illuminating. How many of you have started a project that used a technology that was 12 month old or younger? The fact is that people find less risk in the new, want to pad their resumes, and want to believe in the miracles of new things…. Because they have to be better than what happened in the past. Simply this is all about fear of failure. Most projects fail, so eliminating as much as you can about how you did the old project will obviously reduce the odds of the same failed result, right?
  • Another great
  • Here we are referring to the requirement itself. There are many other things that can be related to the requirement, but its specification should not contain anything but a clear statement of the need. We can document a requirement to death, just don’t confuse the requirement with its background material. The primary issue is that it is too easy to loose a requirement when mixed with this other information.
  • Relationships to other requirements or traces to information that lead to a requirement help show
  • Domain – Security, standard functionality, performance, industry standards, languages, etc.Usability – Data validation, help, flow, understandability, etc.Other parts of delivery – Naming, help for marketing, QA, testing, etc.Technology– Required work for use of a technology, etc.Corporate/Industry/Government – logging, security, authentication, metrics, business logic (related to laws or mandates) , etc.
  • Evo andPlanguage were developed by Tom Gilb. Evo is an iterative methodology that is very Agile.Evo concentrates on key questions and software metrics. It is a little known fact that Tom Gilb invented the term “Software Metrics” Also: Agile and Iterative Development: A Manager's Guide by Craig Larman
  • From "Rich Requirement Specifications: the use of Planguage to clarify requirements” by Tom Gilb.
  • There are a lot of issues with delivery. Primarily is that scope and priorities change.
  • This is one of the really nice things about modeled requirements like we have in SysML. The less room you have, the more precise you need to be. How many of you look at requirements written in Word and can’t actually find the executable requirement?
  • No Silver Bullet – Brooks
  • Plan-Do-Study-Act (PDSA) Shewhart/Deming is a fundamental process for success. Kind of obvious now about our company name
  • Origin: John Mayo-Smith’s Information Week article entitled Two Ways to Build a Pyramid.
  • Bex Huff rebuttal
  • Modeling Requirements Narrated2

    1. 1. Mixing Requirements, Modeling, and Code (Java)Finally software requirements that aren&apos;t lip service!<br />Daniel Brookshier, Chief Architect No Magic Inc.<br /><br />
    2. 2. Requirements of the Presentation<br />Learn why formal requirements are still important<br />Learn how to model requirements with SysML<br />Learn how requirements are much better via SysML<br />Learn how requirements via a tool is compatible with Agile<br />See how we can better manage requirements with standard UML tools<br />Manage unit tests and Java code via requirement models<br />
    3. 3. Requirements Suck!!!<br />Requirements failure!<br />Written by the wrong people<br />Poorly written<br />Verbose and confusing or terse ambiguous<br />Written and forgotten<br />Overdone or underdone<br />
    4. 4. The plan is nothing; 
the planning is everything. 
Dwight Eisenhower<br />
    5. 5. Can’t live with them, can’t live without them!<br />Scopes work<br />Discovers goals<br />Sharable viewpoint<br />Trace to design<br />Traced to work<br />Trace to tests<br />Find related capability<br />Ensures completeness<br />Links iterations<br />Aids Re-use <br />Avoids the problems of dementia<br />
    6. 6. Waterfall or Agile Requirements?<br />Waterfowl <br />Exhaustive up front<br />Set them in concrete!<br />Forget!<br />Agile<br />Create top requirements<br />Focus on functional<br />Focus on performance<br />Clear language<br />Detail/Refine/change requirements on each iteration<br />Forget<br />Repeat<br />
    7. 7.
    8. 8. Modeling Requirements in UMLSysML Requirements 101<br />
    9. 9. What is SysML?<br />SysML = Systems Modeling Language<br />Extension of UML<br />Oriented at modeling systems and system of systems<br />Various levels of detail<br />More rigor than UML<br />Requirements are part of SysML<br />Designed for use in models<br />Extensible<br />Model abstract to detailed requirements<br />Derive requirements from other requirements<br />Reuse requirements from other models<br />Traceability to design, tests, and other information<br />
    10. 10. What is SysML really?Semantic Tagging!<br />The problem is too many words<br />The solution is to tag words and link to context<br />SysML uses tags on UML to create semantics of Requirements<br />
    11. 11. What’s The Goal of SysML Requirements?<br />Requirement Modeling:<br />Atomic Requirements<br />Reusable<br />Flexible linkages<br />Where they come from?<br />How are they related?<br />What satisfies?<br />What verifies?<br />
    12. 12. The Goal!!!<br />
    13. 13. Where’s the Java?<br />What?<br />JUnit Tests<br />Classes, Interfaces<br />Attributes<br />Methods<br />Annotations or JavaDoc<br />How?<br />Models<br />Reverse Engineering<br />Forward Engineering<br />(MDA) Code Generation<br />Top Level Component Modeling<br />
    14. 14. Problem: Requirement management and traceability<br />Tracing shows progress and compliance<br />Tools can further use models for generation<br />Gaps can be analyzed<br />Change is manageable<br />Impact of change can be discovered<br />Requirements re-used<br />Once source of truth!<br />
    15. 15. SysML Artifacts<br />Requirement types<br />Business<br />Design Constraint<br />Functional<br />Interface<br />Performance<br />Physical<br />Usability<br />Requirement Trace<br />Derived<br />Refines<br />Trace<br />Copy<br />Compliance Trace<br />Verify (test)<br />Satisfy (implementation)<br />Other<br />Containment<br />Notes <br />Comments<br />
    16. 16. The Benefits of Modeling<br />Based on the use of the stereotype<br />Allows UML modelers to annotate elements<br />Instance data applied to model data<br />Adds additional context<br />Various uses<br />Annotations (semantics and transformation)<br />Planning data<br />Build data<br />Management data<br />Enterprise data<br />Requirements<br />
    17. 17. Modeling Relationship<br />Dependency<br />Most of the relationships are base on Dependency<br />We have a direction from the client to the source.<br />If the source is removed, the client is no longer required<br />If the source changes, the client should meet the new source contract<br />
    18. 18. Using SysML Requirements<br />Process for model-based requirements<br />
    19. 19. Standard Requirements<br />
    20. 20. Corporate Requirements<br />
    21. 21. Application Requirements<br />
    22. 22. Application Derived from Corporate Requirement<br />
    23. 23. Augmenting Requirements<br />Requirements alone suck!<br />Use Cases<br />Stories (Agile)<br />Named User Stories (Cooper’s Interaction Design)<br />Storyboards<br />Class Responsibility Collaborator (CRC cards)<br />Activity-Based Modeling<br />Jackson Structured Programming (JSP)<br />Don’t use requirements alone!<br />Good for discovery, bad for maintenance<br />Issues of clarity<br />Hard to allocate to work to be performed<br />Maintenance is difficult<br />Not formal<br />Link to requirements!<br />
    24. 24. Use Cases<br />
    25. 25. Refinement Trace<br />
    26. 26. If it can fail, test it!<br />Everything human is at least a little bit broken. <br />
David Weinberger 
from The Clue Train Manifesto<br />
    27. 27. Verify Trace<br />
    28. 28. Icky Sticky GUI<br />
    29. 29. Very Sticky Requirements<br />
    30. 30. Trace The Use Case<br />
    31. 31. Tracing to Java!<br />
    32. 32. Poor Traceability!!!!<br />
    33. 33. Satisfy Trace<br />
    34. 34. Satisfy Components<br />
    35. 35. Capturing Other Data<br />Estimations<br />Hours<br />Costs<br />Assignments<br />Risks<br />Complexity<br />Unknowns<br />Assumptions<br />Priority<br />Customer priority<br />Development sequence<br />Success<br />Completed<br />Tested<br />
    36. 36. Estimating and Prioritizing in the Model<br />
    37. 37. Gaps & Tracing<br />
    38. 38. Tracing Satisfy/Verify<br />
    39. 39. Refined Requirements<br />
    40. 40. Overall Process<br />Easy steps<br />Create requirements<br />Sort and prioritize<br />Allocate to your project via components<br />Design/Estimate/Link<br />Sort and prioritize<br />Do it!!!<br />Validate<br />Repeat<br />
    41. 41. Focus on Development<br />Design/Develop Phase<br />Choose/Create components<br />Link with Requirement<br />Create Tests<br />Estimate Design<br />Estimate Hours/Cost<br />Re-wire Requirements to Tests/Classes where needed<br />
    42. 42.
    43. 43. Take the paper out of requirements on paper<br />Traceability to Design<br />Reporting<br />One source of truth<br />Trace to the stakeholder<br />Simple to add metrics<br />Simple to add production information<br />Navigation between requirements and design<br />Automations<br />Automatic annotation of code<br />Analysis of the model<br />Linking to other tools<br />Dynamic documentation<br />On demand reporting<br />
    44. 44. Java Annotations<br />Taking advantage of code that knows its requirements, use cases, and test cases.<br />
    45. 45. Add Data to JavaDoc and logging<br />Annotate code with requirement satisfy/verify<br />Goal: Avoids looking at bellybutton for documentation<br />Synchronizes docs to code<br />Use annotations to inject data into logging<br />Can be used to annotate tests<br />Aid analysis<br />Work in progress!<br />
    46. 46. Defining Java Annotations<br />
    47. 47. Using Satisfy Annotation<br />Class has Satisfy Relationship<br />Other methods have not been traced to requirement<br />Some methods may not yet be added to inventory<br />
    48. 48. Annotation Process<br />Use annotated models with data for code<br />Create annotations<br />Auto populate known relationships<br />Use scripting!<br />Use the annotation tools to change code or add info to<br />Source code<br />Logging<br />Improve test/debug context<br />Improve error messages without the work <br />
    49. 49. Any fool can make a specification complicated. 
It takes skill to make it simple<br />
    50. 50. We Are Not A Charity<br />Slides my boss says I’m required to include<br />
    51. 51. You’re invited for three days of:<br />Great networking with hundreds of architects<br />Multiple training sessions: UML, UPDM, SysML, SOA, Requirements, from No Magic and IASA<br />Leading industry keynote presentations<br />Three parallel tracks: Technology, Enterprise Architecture and Systems Engineering<br />IASA IT Architect and SysML certification programs offered during conference <br />
    52. 52. Gaylord Texan Resort & Hotel, Grapevine, Texas<br />Special pricing for ITARC Austin attendees (come to our table for a one time 50% Conference discount) <br />
    53. 53. End of part 1Thank You!<br />Daniel Brookshier<br /><br />Can ye make a model of it? 
If ye can, ye understands it, 
and if ye canna, ye dinna! 
<br />- Lord Kelvin<br />
    54. 54. A new road for Requirements<br />
    55. 55. Writing Requirements<br />A short course!<br />
    56. 56. Thinking Traceability<br />What level do you want to trace requirements<br />Do you add test validation results to code<br />Can this go both ways (inadvisable)<br />What other data annotates the code?<br />Requirement owner<br />Related requirements<br />Use Case<br />Other…<br />
    57. 57. It’s where you want to go<br />Would you tell me please, which way I ought to go from here?<br /> 
That depends a good deal on where you want to get to, said the cat. 
<br />I don&apos;t much care where -, said Alice. 
<br />Then it doesn&apos;t matter which way you go, said the cat. 
<br />Lewis Carroll, Alice in Wonderland, Chapter 6. <br />Quoted by Tom Gilb, Competitive Engineering<br />
Illustration by Sir John Tenniel<br />
    58. 58. Preventing Requirements Failure<br />
    59. 59. People Issues<br />Fear of failure<br />Fear of success<br />Procrastination<br />Selective memory<br />Antidotal Evidence<br />Inertia<br />Competence in task<br />Politics (the bully)<br />
    60. 60. Environmental Issues<br />Time<br />Tools<br />Money<br />Availability of experts<br />Organization goals<br />Data<br />
    61. 61. Create Small Success<br />Prove your ideas<br />Educate<br />Create a chain of value<br />Show ROI<br />
    62. 62. Negative Thinking is Negative<br />Cynicisim<br />Negatisim<br />Defeatisim<br />Escapisim<br />Delayisim<br />Seventy percent of consumers <br />read reviews.<br /> 75% say they wouldn&apos;t buy a product <br />after reading three negative reviews. <br />
    63. 63. Fears<br />Fear of failure<br />Fear of success<br />Fear of rejection<br />Fear of producing low quality work<br />Fear of risk<br />Fear of pain<br />
    64. 64. The Lizard Brain<br />Food<br />Shelter<br />Status<br />Value to the pack<br />
    65. 65. The secret of clear requirements:<br />Be Brief<br />Less text usually leads to less confusion.<br />One sentence is the ideal requirement. <br />Broad requirements should contain specific requirements<br />Break down requirements to finer requirements<br />Divide into required (core) and optional<br />
    66. 66. Clear and Unambiguous<br />Just the requirement<br />Don’t justify<br />Don’t give examples<br />Don’t relate to other requirements<br />Don’t specify implementation<br />Be careful of exceptions<br />Say what is needed, not how<br />
    67. 67. Testable/Verifiable<br />Requirements need to be verifiable<br />What is the test?<br />Conditions?<br />Method?<br />Desired result?<br />Avoid the happy path too!<br />Negative conditions?<br />Negative results?<br />
    68. 68. Refining Requirements<br />
    69. 69. Give Multiple Examples<br />One example is easily confused with a mandate.<br />Two examples show possibility<br />Multiple examples cover expected range<br />Tests (positive, negative, destructive) are better<br />
    70. 70. Who Owns It?<br />Document the owner<br />Owner should review<br />Include contact information<br />Owner should review any changes<br />
    71. 71. Related To What?<br />Context is everything for many requirements<br />Use dependencies<br />When removed, eliminate need to implement<br />When existing, show need for related<br />Shows reason leading to need for requirement<br />Circular references are ok<br />
    72. 72. Requirement of Requirements<br />Some requirements are always there<br />Requirements can be re-used and serve as derived or refined<br />Trace to other requirements:<br />Domain<br />Usability<br />Other parts of delivery<br />Technology<br />Corporate/Industry/Government<br />
    73. 73. Some things are obvious<br />Evo - Evolutionary Project Management<br />Requirements Practices<br />Find stakeholders<br />Top ten requirements<br />Clear Requirements (Planguage)<br />Functional requirements<br />Performance Requirements<br />
    74. 74. What is a requirement?<br />Ten Principals of Requirements (Gilb)<br />1) The Requirement should be a Reusable Object.<br />2) The requirement should give information allowing us to check its quality.<br />3) The requirement should explicitly document its relationships to designs, tests, stakeholders, sources, use cases and all other interesting things<br />4) The requirement should be a future state, and not unintentionally a design to get there.<br />5) Complex requirements should have a clear hierarchy, not a vague summary.<br />
    75. 75. 6) Requirements should be rich in information allowing us to determine their current priority.<br />7) Performance and cost requirements should contain a rich specification of targets, constraints, and time/space/event qualifiers.<br />8) Any class of requirement should be specified, and the classes should be well defined. <br />9) The requirement should be rich in information that allows us to understand, spot, analyze, present, and mitigate risks of deviation from that requirement.<br />10) The requirement should be easy to specify without special tools, and it should be easy for any enterprise to extend or modify the requirement language to their own purposes.<br />
    76. 76. Challenges of Long Term Delivery<br />Stakeholders change<br />Developers change<br />Testers change<br />Tools change<br />Process change<br />Emergencies arise<br />Mistakes are made<br />Systems fail<br />Partners are gained<br />Partners are lost<br />Change results in changes in requirements<br />
    77. 77. Some things never change<br />Stable Requirements<br />Usability<br />Efficiency<br />Facts<br />Behavior<br />Laws<br />Long term goals<br />Tolerating mistakes<br />Preventing mistakes<br />
    78. 78. Requirements verses Refining Requirements<br />Requirements <br />Small and easy to parse<br />Atomic<br />Most are unrelated to intent, not implementation<br />Simple to manage<br />Easily integrated with models<br />Use case, stories, and other methods <br />Not atomic<br />Hard to parse<br />Usually related to implementation, not intent<br />Hard to manage<br />Harder to integrate into models<br />Don’t confuse requirements with discovery or refining requirements<br />
    79. 79. Can you hear me now!<br />First law of requirements engineering<br />Listen!<br />
    80. 80. Do it all or do what you need…<br />Information is power<br />Too much information is unfocused power<br />Too little is… too little!<br />
    81. 81. Writing a requirement is never bad<br />What is bad?<br />Poor refinement<br />Wrong requirement<br />Poor estimates<br />Too many discovered in each iteration<br />Ignoring basic requirements<br />Bad programming<br />
    82. 82. If you don&apos;t know where you&apos;re going, 
you&apos;re unlikely to end up there. - Forrest Gump<br />
    83. 83. Requirement Goals<br />Small, implementable specifications<br />Measurable or testable<br />Easy to manage<br />Reusable<br />Traced to implementation (satisfy)<br />Traced to tests (verify)<br />See the impact of change<br />See gaps<br />
    84. 84.      “To be stupid, selfish, and have good health are three requirements for happiness, though if stupidity is lacking, all is lost.” - Gustave Flaubert <br />
    85. 85. Any fool can make a specification complicated. 
It takes skill to make it simple<br />
    86. 86. Writing Requirements<br />Simple is better<br />Atomic statements of facts/needs/goals<br />Generally just a sentence<br />Keep examples separate from the requirement<br />Requirements need a justification!<br />
    87. 87. Don’t overdo it<br />Avoid design details<br />Build requirements from general to specific<br />Don’t get too specific until you are considering an iteration<br />Be specific about the type of requirement<br />Are the words testable?<br />
    88. 88. Delivery is not necessarily the best time to discover the user requirements. - Alexander&apos;s 17th Law of Requirements<br />
    89. 89. There are requirements and then there are requirements<br /><ul><li>There are several types of requirements</li></ul>Always true<br />Incorrect<br />Forgotten/Unknown<br />Competitive/Situational<br />Requirements change due to:<br />Competition or events create or change business requirements <br />Discovered requirements during development<br />Errors discovered <br />
    90. 90. There&apos;s no point in being exact about something if you don&apos;t even know what you&apos;re talking about. -John von Neumann<br />
    91. 91. Discovering Requirements<br />The key to requirements is discovery<br />Thinking about requirements lead to related requirements<br />Thinking about general requirements leads to detail requirements<br />Thinking about design details leads to design requirements<br />
    92. 92. Cameo ALM - Cameo RQ+<br />
    93. 93. Architecture Werewolves Still Byte <br />There is no such thing as a silver bullet <br />Germ theory replaced mystical theories and resulted in careful process to manage health<br />We must replace magical thinking with process<br />There is no free lunch!<br />
    94. 94. Your next step<br />There is only one move that really counts: <br />The next one.<br />—Chess master Jose Capablanca<br />
    95. 95. Thank You!<br />Can ye make a model of it? 
If ye can, ye understands it, 
and if ye canna, ye dinna! 
<br />- Lord Kelvin<br />
    96. 96. Additional Slides<br />
    97. 97. Agile/Scrum/XP<br />Requirements are still ok<br />With very detailed requirements Agile methodologies are unaffected and can run smoother<br />Easy to prioritize when requirements are complete<br />Variations of priorities is easier to manage within the context of pre-defined requirements<br />With defined requirements, establishing completion of goals is easier to prove <br />
    98. 98. To be Agile is to use what works<br />Other side of the Agile coin<br />Tools help individuals interact and serve as a base between iterations<br />Documentation leads to software that meets an agreed goal<br />Contracts protect the customer and the supplier<br />A plan reduces the need for change and manages it<br />Agile Manifesto:<br />Welcome changing requirements, even late in 
development. <br />Requirements Using SysML<br />Maintain a list of existing requirements<br />Know the gaps and related requirements<br />Use requirements to find existing code or patterns<br />Link with tests (Test First Methodology)<br />
    99. 99. Those who cannot remember the past are condemned to repeat it. 
or by interpolation: <br />
Those who have never heard of good system development practice are condemned to reinvent it.<br />Those who remember the past are doomed to a sense of dejavu.
(or, if you wait long enough, engineering fashion will come round again) <br />- Martin Feather<br />
    100. 100. Plan-Do-Study-Act (PDSA)Shewhart/Deming<br />Plan: Requirements<br />Do: Which, and when!<br />Study: How much and how well<br />Act: Produce!<br />
    101. 101. Plan-Do-Study-Act (PDSA) Shewhart/Deming<br />PDSA is process<br />Plan it<br />Do it<br />Observing results <br />Refactor as needed <br />Simple concepts<br />Each step important<br />No shortcuts <br />No Magic<br />Just Hard Work<br />
    102. 102. Plan & Do<br />Step 1: Plan<br />Plan the test or observation, including a plan for collecting data.<br />State the objective of the test.<br />Make predictions about what will happen and why.<br />Develop a plan to test the change. (Who? What? When? Where? What data need to be collected?)<br />Step 2: Do<br />Try out the test on a small scale.<br />Carry out the test.<br />Document problems and unexpected observations.<br />Begin analysis of the data.<br />
    103. 103. Study & Act<br />Step 3: Study<br />Set aside time to analyze the data and study the results.<br />Complete the analysis of the data.<br />Compare the data to your predictions.<br />Summarize and reflect on what was learned.<br />Step 4: Act <br />Refine the change, based on what was learned from the test.<br />Determine what modifications should be made.<br />Prepare a plan for the next test.<br />
    104. 104. Agile and the Pyramid<br />A fantasy wrapped in misdirection<br />
    105. 105. Agile Manifesto<br />Agile Manifesto<br />Individuals and interactions over processes and tools <br />Working software over comprehensive documentation<br />Customer collaboration over contract negotiation<br />Responding to change over following a plan <br />Agile does help stop abuse, but you can go too far!<br />No process or tools leads to anarchy and lack of accounting<br />No documentation causes confusion and more anarchy<br />Lack of contracts… lack of payment<br />No plan leads to reactive change missing long term goals <br />
    106. 106. Pyramid of Agile<br />Problems with the Agile pyramid (Alex Papadimoulis)<br />Doesn’t work well for the 3D shape<br />What about the foundation?<br />Inner chamber design limited to initial build<br />Key points:<br />Tough to do with stone<br />The plan is important (for either goal)<br />What pharaoh is going to settle for the smaller pyramid?<br />This story is a story, a lie <br />
    107. 107. The Rebuttal (Bex Huff)<br />Software architecture is not architecture (software vs physical)<br />Buildings always have a custom foundation (yikes!)<br />You can patch a building with very few side effects<br />Enabling communication between 2 buildings rarely causes their destruction<br />Plumbing and waterworks design is a much better analogy, and not just because the internet is full of tubes<br />So, Agile supporters use a false building analogy<br />Anti-agile supporter tears it down with an understanding of buildings<br />Agile supporter says building analogies are a scam because software is not a building, but pluming <br />Truth: Software is not simple and under thinking is folly<br />
    108. 108. Software and hard drugs 
are the only two professions 
that refer to their customers as &apos;users&apos;. <br />
- Anon<br />
    109. 109. For a successful technology, 
reality must take precedence over public relations, 
for nature cannot be fooled. <br />
Richard P Feynman (during the Challenger inquiry)<br />
    110. 110. Writing Requirements<br />The cobbler&apos;s children go unshod. 
<br />which of course means:<br /> 
Requirements Engineers never write down their their own requirements.<br />
    111. 111. Tests for Requirements<br />
    112. 112. Observation<br />
    113. 113. Input Causes Output<br />
    114. 114. Action Causes Reaction<br />
    115. 115. Performance<br />
    116. 116. Accuracy<br />
    117. 117. Transformation Reversibility<br />
    118. 118. Usability Metrics<br />