Modeling Requirements Narrated2
Upcoming SlideShare
Loading in...5
×
 

Modeling Requirements Narrated2

on

  • 1,513 views

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 ...

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.

Statistics

Views

Total Views
1,513
Views on SlideShare
1,513
Embed Views
0

Actions

Likes
0
Downloads
19
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 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 http://en.wikipedia.org/wiki/Jackson_Structured_ProgrammingCRC http://en.wikipedia.org/wiki/Class-Responsibility-Collaboration_cardCooper InteractionDesign http://en.wikipedia.org/wiki/Interaction_design
  • 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?http://www.internetretailing.net/news/three-strikes-and-youre-out-research-shows-how-buyers-use-customer-reviews/
  • 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”http://www.btt-research.com/rich%20requirements%20specs.htmhttp://gilb.com/community/tiki-page.php?pageName=Evolutionary-Project-Managementhttp://www.livespecs.com/downloads/ClearSpecs20V01_Quantifying%20Quality%20Requirements.pdfSee 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.http://www.btt-research.com/rich%20requirements%20specs.htm
  • 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 http://www.lips.utexas.edu/ee382c-15005/Readings/Readings1/05-Broo87.pdf
  • 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.http://www.informationweek.com/news/software/development/showArticle.jhtml?articleID=6507351Rebuttal: http://thedailywtf.com/Articles/The-Great-Pyramid-of-Agile.aspx
  • Bex Huff rebuttalhttp://bexhuff.com/2007/05/software-architecture-not-building-architecture

Modeling Requirements Narrated2 Modeling Requirements Narrated2 Presentation Transcript

  • Mixing Requirements, Modeling, and Code (Java)Finally software requirements that aren't lip service!
    Daniel Brookshier, Chief Architect No Magic Inc.
    DanielB@NoMagic.com
  • Requirements of the Presentation
    Learn why formal requirements are still important
    Learn how to model requirements with SysML
    Learn how requirements are much better via SysML
    Learn how requirements via a tool is compatible with Agile
    See how we can better manage requirements with standard UML tools
    Manage unit tests and Java code via requirement models
  • Requirements Suck!!!
    Requirements failure!
    Written by the wrong people
    Poorly written
    Verbose and confusing or terse ambiguous
    Written and forgotten
    Overdone or underdone
  • The plan is nothing; 
the planning is everything. 
Dwight Eisenhower
  • Can’t live with them, can’t live without them!
    Scopes work
    Discovers goals
    Sharable viewpoint
    Trace to design
    Traced to work
    Trace to tests
    Find related capability
    Ensures completeness
    Links iterations
    Aids Re-use
    Avoids the problems of dementia
  • Waterfall or Agile Requirements?
    Waterfowl
    Exhaustive up front
    Set them in concrete!
    Forget!
    Agile
    Create top requirements
    Focus on functional
    Focus on performance
    Clear language
    Detail/Refine/change requirements on each iteration
    Forget
    Repeat
  • Modeling Requirements in UMLSysML Requirements 101
  • What is SysML?
    SysML = Systems Modeling Language
    Extension of UML
    Oriented at modeling systems and system of systems
    Various levels of detail
    More rigor than UML
    Requirements are part of SysML
    Designed for use in models
    Extensible
    Model abstract to detailed requirements
    Derive requirements from other requirements
    Reuse requirements from other models
    Traceability to design, tests, and other information
  • What is SysML really?Semantic Tagging!
    The problem is too many words
    The solution is to tag words and link to context
    SysML uses tags on UML to create semantics of Requirements
  • What’s The Goal of SysML Requirements?
    Requirement Modeling:
    Atomic Requirements
    Reusable
    Flexible linkages
    Where they come from?
    How are they related?
    What satisfies?
    What verifies?
  • The Goal!!!
  • Where’s the Java?
    What?
    JUnit Tests
    Classes, Interfaces
    Attributes
    Methods
    Annotations or JavaDoc
    How?
    Models
    Reverse Engineering
    Forward Engineering
    (MDA) Code Generation
    Top Level Component Modeling
  • Problem: Requirement management and traceability
    Tracing shows progress and compliance
    Tools can further use models for generation
    Gaps can be analyzed
    Change is manageable
    Impact of change can be discovered
    Requirements re-used
    Once source of truth!
  • SysML Artifacts
    Requirement types
    Business
    Design Constraint
    Functional
    Interface
    Performance
    Physical
    Usability
    Requirement Trace
    Derived
    Refines
    Trace
    Copy
    Compliance Trace
    Verify (test)
    Satisfy (implementation)
    Other
    Containment
    Notes
    Comments
  • The Benefits of Modeling
    Based on the use of the stereotype
    Allows UML modelers to annotate elements
    Instance data applied to model data
    Adds additional context
    Various uses
    Annotations (semantics and transformation)
    Planning data
    Build data
    Management data
    Enterprise data
    Requirements
  • Modeling Relationship
    Dependency
    Most of the relationships are base on Dependency
    We have a direction from the client to the source.
    If the source is removed, the client is no longer required
    If the source changes, the client should meet the new source contract
  • Using SysML Requirements
    Process for model-based requirements
  • Standard Requirements
  • Corporate Requirements
  • Application Requirements
  • Application Derived from Corporate Requirement
  • Augmenting Requirements
    Requirements alone suck!
    Use Cases
    Stories (Agile)
    Named User Stories (Cooper’s Interaction Design)
    Storyboards
    Class Responsibility Collaborator (CRC cards)
    Activity-Based Modeling
    Jackson Structured Programming (JSP)
    Don’t use requirements alone!
    Good for discovery, bad for maintenance
    Issues of clarity
    Hard to allocate to work to be performed
    Maintenance is difficult
    Not formal
    Link to requirements!
  • Use Cases
  • Refinement Trace
  • If it can fail, test it!
    Everything human is at least a little bit broken. 
    
David Weinberger 
from The Clue Train Manifesto
  • Verify Trace
  • Icky Sticky GUI
  • Very Sticky Requirements
  • Trace The Use Case
  • Tracing to Java!
  • Poor Traceability!!!!
  • Satisfy Trace
  • Satisfy Components
  • Capturing Other Data
    Estimations
    Hours
    Costs
    Assignments
    Risks
    Complexity
    Unknowns
    Assumptions
    Priority
    Customer priority
    Development sequence
    Success
    Completed
    Tested
  • Estimating and Prioritizing in the Model
  • Gaps & Tracing
  • Tracing Satisfy/Verify
  • Refined Requirements
  • Overall Process
    Easy steps
    Create requirements
    Sort and prioritize
    Allocate to your project via components
    Design/Estimate/Link
    Sort and prioritize
    Do it!!!
    Validate
    Repeat
  • Focus on Development
    Design/Develop Phase
    Choose/Create components
    Link with Requirement
    Create Tests
    Estimate Design
    Estimate Hours/Cost
    Re-wire Requirements to Tests/Classes where needed
  • Take the paper out of requirements on paper
    Traceability to Design
    Reporting
    One source of truth
    Trace to the stakeholder
    Simple to add metrics
    Simple to add production information
    Navigation between requirements and design
    Automations
    Automatic annotation of code
    Analysis of the model
    Linking to other tools
    Dynamic documentation
    On demand reporting
  • Java Annotations
    Taking advantage of code that knows its requirements, use cases, and test cases.
  • Add Data to JavaDoc and logging
    Annotate code with requirement satisfy/verify
    Goal: Avoids looking at bellybutton for documentation
    Synchronizes docs to code
    Use annotations to inject data into logging
    Can be used to annotate tests
    Aid analysis
    Work in progress!
  • Defining Java Annotations
  • Using Satisfy Annotation
    Class has Satisfy Relationship
    Other methods have not been traced to requirement
    Some methods may not yet be added to inventory
  • Annotation Process
    Use annotated models with data for code
    Create annotations
    Auto populate known relationships
    Use scripting!
    Use the annotation tools to change code or add info to
    Source code
    Logging
    Improve test/debug context
    Improve error messages without the work
  • Any fool can make a specification complicated. 
It takes skill to make it simple
  • We Are Not A Charity
    Slides my boss says I’m required to include
  • You’re invited for three days of:
    Great networking with hundreds of architects
    Multiple training sessions: UML, UPDM, SysML, SOA, Requirements, from No Magic and IASA
    Leading industry keynote presentations
    Three parallel tracks: Technology, Enterprise Architecture and Systems Engineering
    IASA IT Architect and SysML certification programs offered during conference
  • Gaylord Texan Resort & Hotel, Grapevine, Texas
    Special pricing for ITARC Austin attendees (come to our table for a one time 50% Conference discount)
  • End of part 1Thank You!
    Daniel Brookshier
    danielB@NoMagic.com
    Can ye make a model of it? 
If ye can, ye understands it, 
and if ye canna, ye dinna! 

    - Lord Kelvin
  • A new road for Requirements
  • Writing Requirements
    A short course!
  • Thinking Traceability
    What level do you want to trace requirements
    Do you add test validation results to code
    Can this go both ways (inadvisable)
    What other data annotates the code?
    Requirement owner
    Related requirements
    Use Case
    Other…
  • It’s where you want to go
    Would you tell me please, which way I ought to go from here?
    
That depends a good deal on where you want to get to, said the cat. 

    I don't much care where -, said Alice. 

    Then it doesn't matter which way you go, said the cat. 

    Lewis Carroll, Alice in Wonderland, Chapter 6.
    Quoted by Tom Gilb, Competitive Engineering
    
Illustration by Sir John Tenniel
  • Preventing Requirements Failure
  • People Issues
    Fear of failure
    Fear of success
    Procrastination
    Selective memory
    Antidotal Evidence
    Inertia
    Competence in task
    Politics (the bully)
  • Environmental Issues
    Time
    Tools
    Money
    Availability of experts
    Organization goals
    Data
  • Create Small Success
    Prove your ideas
    Educate
    Create a chain of value
    Show ROI
  • Negative Thinking is Negative
    Cynicisim
    Negatisim
    Defeatisim
    Escapisim
    Delayisim
    Seventy percent of consumers
    read reviews.
    75% say they wouldn't buy a product
    after reading three negative reviews.
  • Fears
    Fear of failure
    Fear of success
    Fear of rejection
    Fear of producing low quality work
    Fear of risk
    Fear of pain
  • The Lizard Brain
    Food
    Shelter
    Status
    Value to the pack
  • The secret of clear requirements:
    Be Brief
    Less text usually leads to less confusion.
    One sentence is the ideal requirement.
    Broad requirements should contain specific requirements
    Break down requirements to finer requirements
    Divide into required (core) and optional
  • Clear and Unambiguous
    Just the requirement
    Don’t justify
    Don’t give examples
    Don’t relate to other requirements
    Don’t specify implementation
    Be careful of exceptions
    Say what is needed, not how
  • Testable/Verifiable
    Requirements need to be verifiable
    What is the test?
    Conditions?
    Method?
    Desired result?
    Avoid the happy path too!
    Negative conditions?
    Negative results?
  • Refining Requirements
  • Give Multiple Examples
    One example is easily confused with a mandate.
    Two examples show possibility
    Multiple examples cover expected range
    Tests (positive, negative, destructive) are better
  • Who Owns It?
    Document the owner
    Owner should review
    Include contact information
    Owner should review any changes
  • Related To What?
    Context is everything for many requirements
    Use dependencies
    When removed, eliminate need to implement
    When existing, show need for related
    Shows reason leading to need for requirement
    Circular references are ok
  • Requirement of Requirements
    Some requirements are always there
    Requirements can be re-used and serve as derived or refined
    Trace to other requirements:
    Domain
    Usability
    Other parts of delivery
    Technology
    Corporate/Industry/Government
  • Some things are obvious
    Evo - Evolutionary Project Management
    Requirements Practices
    Find stakeholders
    Top ten requirements
    Clear Requirements (Planguage)
    Functional requirements
    Performance Requirements
  • What is a requirement?
    Ten Principals of Requirements (Gilb)
    1) The Requirement should be a Reusable Object.
    2) The requirement should give information allowing us to check its quality.
    3) The requirement should explicitly document its relationships to designs, tests, stakeholders, sources, use cases and all other interesting things
    4) The requirement should be a future state, and not unintentionally a design to get there.
    5) Complex requirements should have a clear hierarchy, not a vague summary.
  • 6) Requirements should be rich in information allowing us to determine their current priority.
    7) Performance and cost requirements should contain a rich specification of targets, constraints, and time/space/event qualifiers.
    8) Any class of requirement should be specified, and the classes should be well defined.
    9) The requirement should be rich in information that allows us to understand, spot, analyze, present, and mitigate risks of deviation from that requirement.
    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.
  • Challenges of Long Term Delivery
    Stakeholders change
    Developers change
    Testers change
    Tools change
    Process change
    Emergencies arise
    Mistakes are made
    Systems fail
    Partners are gained
    Partners are lost
    Change results in changes in requirements
  • Some things never change
    Stable Requirements
    Usability
    Efficiency
    Facts
    Behavior
    Laws
    Long term goals
    Tolerating mistakes
    Preventing mistakes
  • Requirements verses Refining Requirements
    Requirements
    Small and easy to parse
    Atomic
    Most are unrelated to intent, not implementation
    Simple to manage
    Easily integrated with models
    Use case, stories, and other methods
    Not atomic
    Hard to parse
    Usually related to implementation, not intent
    Hard to manage
    Harder to integrate into models
    Don’t confuse requirements with discovery or refining requirements
  • Can you hear me now!
    First law of requirements engineering
    Listen!
  • Do it all or do what you need…
    Information is power
    Too much information is unfocused power
    Too little is… too little!
  • Writing a requirement is never bad
    What is bad?
    Poor refinement
    Wrong requirement
    Poor estimates
    Too many discovered in each iteration
    Ignoring basic requirements
    Bad programming
  • If you don't know where you're going, 
you're unlikely to end up there. - Forrest Gump
  • Requirement Goals
    Small, implementable specifications
    Measurable or testable
    Easy to manage
    Reusable
    Traced to implementation (satisfy)
    Traced to tests (verify)
    See the impact of change
    See gaps
  •      “To be stupid, selfish, and have good health are three requirements for happiness, though if stupidity is lacking, all is lost.” - Gustave Flaubert
  • Any fool can make a specification complicated. 
It takes skill to make it simple
  • Writing Requirements
    Simple is better
    Atomic statements of facts/needs/goals
    Generally just a sentence
    Keep examples separate from the requirement
    Requirements need a justification!
  • Don’t overdo it
    Avoid design details
    Build requirements from general to specific
    Don’t get too specific until you are considering an iteration
    Be specific about the type of requirement
    Are the words testable?
  • Delivery is not necessarily the best time to discover the user requirements. - Alexander's 17th Law of Requirements
  • There are requirements and then there are requirements
    • There are several types of requirements
    Always true
    Incorrect
    Forgotten/Unknown
    Competitive/Situational
    Requirements change due to:
    Competition or events create or change business requirements
    Discovered requirements during development
    Errors discovered
  • There's no point in being exact about something if you don't even know what you're talking about. -John von Neumann
  • Discovering Requirements
    The key to requirements is discovery
    Thinking about requirements lead to related requirements
    Thinking about general requirements leads to detail requirements
    Thinking about design details leads to design requirements
  • Cameo ALM - Cameo RQ+
  • Architecture Werewolves Still Byte
    There is no such thing as a silver bullet
    Germ theory replaced mystical theories and resulted in careful process to manage health
    We must replace magical thinking with process
    There is no free lunch!
  • Your next step
    There is only one move that really counts:
    The next one.
    —Chess master Jose Capablanca
  • Thank You!
    Can ye make a model of it? 
If ye can, ye understands it, 
and if ye canna, ye dinna! 

    - Lord Kelvin
  • Additional Slides
  • Agile/Scrum/XP
    Requirements are still ok
    With very detailed requirements Agile methodologies are unaffected and can run smoother
    Easy to prioritize when requirements are complete
    Variations of priorities is easier to manage within the context of pre-defined requirements
    With defined requirements, establishing completion of goals is easier to prove
  • To be Agile is to use what works
    Other side of the Agile coin
    Tools help individuals interact and serve as a base between iterations
    Documentation leads to software that meets an agreed goal
    Contracts protect the customer and the supplier
    A plan reduces the need for change and manages it
    Agile Manifesto:
    Welcome changing requirements, even late in 
development.
    Requirements Using SysML
    Maintain a list of existing requirements
    Know the gaps and related requirements
    Use requirements to find existing code or patterns
    Link with tests (Test First Methodology)
  • Those who cannot remember the past are condemned to repeat it. 
or by interpolation:
    
Those who have never heard of good system development practice are condemned to reinvent it.
    Those who remember the past are doomed to a sense of dejavu.
(or, if you wait long enough, engineering fashion will come round again)
    - Martin Feather
  • Plan-Do-Study-Act (PDSA)Shewhart/Deming
    Plan: Requirements
    Do: Which, and when!
    Study: How much and how well
    Act: Produce!
  • Plan-Do-Study-Act (PDSA) Shewhart/Deming
    PDSA is process
    Plan it
    Do it
    Observing results
    Refactor as needed
    Simple concepts
    Each step important
    No shortcuts
    No Magic
    Just Hard Work
  • Plan & Do
    Step 1: Plan
    Plan the test or observation, including a plan for collecting data.
    State the objective of the test.
    Make predictions about what will happen and why.
    Develop a plan to test the change. (Who? What? When? Where? What data need to be collected?)
    Step 2: Do
    Try out the test on a small scale.
    Carry out the test.
    Document problems and unexpected observations.
    Begin analysis of the data.
  • Study & Act
    Step 3: Study
    Set aside time to analyze the data and study the results.
    Complete the analysis of the data.
    Compare the data to your predictions.
    Summarize and reflect on what was learned.
    Step 4: Act
    Refine the change, based on what was learned from the test.
    Determine what modifications should be made.
    Prepare a plan for the next test.
  • Agile and the Pyramid
    A fantasy wrapped in misdirection
  • Agile Manifesto
    Agile Manifesto
    Individuals and interactions over processes and tools
    Working software over comprehensive documentation
    Customer collaboration over contract negotiation
    Responding to change over following a plan
    Agile does help stop abuse, but you can go too far!
    No process or tools leads to anarchy and lack of accounting
    No documentation causes confusion and more anarchy
    Lack of contracts… lack of payment
    No plan leads to reactive change missing long term goals
  • Pyramid of Agile
    Problems with the Agile pyramid (Alex Papadimoulis)
    Doesn’t work well for the 3D shape
    What about the foundation?
    Inner chamber design limited to initial build
    Key points:
    Tough to do with stone
    The plan is important (for either goal)
    What pharaoh is going to settle for the smaller pyramid?
    This story is a story, a lie
  • The Rebuttal (Bex Huff)
    Software architecture is not architecture (software vs physical)
    Buildings always have a custom foundation (yikes!)
    You can patch a building with very few side effects
    Enabling communication between 2 buildings rarely causes their destruction
    Plumbing and waterworks design is a much better analogy, and not just because the internet is full of tubes
    So, Agile supporters use a false building analogy
    Anti-agile supporter tears it down with an understanding of buildings
    Agile supporter says building analogies are a scam because software is not a building, but pluming
    Truth: Software is not simple and under thinking is folly
  • Software and hard drugs 
are the only two professions 
that refer to their customers as 'users'. 
    
- Anon
  • For a successful technology, 
reality must take precedence over public relations, 
for nature cannot be fooled. 
    
Richard P Feynman (during the Challenger inquiry)
  • Writing Requirements
    The cobbler's children go unshod. 

    which of course means:
    
Requirements Engineers never write down their their own requirements.
  • Tests for Requirements
  • Observation
  • Input Causes Output
  • Action Causes Reaction
  • Performance
  • Accuracy
  • Transformation Reversibility
  • Usability Metrics