IT'S YOUR FUTURE...WHAT DOES IT LOOK LIKE?

The 2007 Women's Business Conference, presented by AWTAustin, is happening on February 7th - only a week away!

You're invited to join professional women in Austin for a day of seminars and presentations that will help you shape your future and make the changes you've always wanted to make, professionally and personally.

The day begins with an energizing breakfast session "Wake up! Your Future is Now", presented by Gay Gaddis, CEO of T3 (The Think Tank), an Austin based advertising success story. At lunch; futurist, poet and author, Dr. Betty Sue Flowers; will inspire you with an interactive session on, "It's your future... what does it look like?"

Cat Callen, who is a Principal Consultant here at Seilevel and also Mayor of Pflugerville, will be speaking on a panel in the morning. The panel is called “Giving Back” and is about closing the loop for generosity and opportunity — a discussion of choices, sacrifices and rewards from women who have made giving back a priority in their lives. Come and hear Cat answer questions on what motivates her, what she has had to give up to give back and the rewards she gets from the choices she has made. Learn how women who make a difference every day find the focus, time, energy and resources to give back in their own unique ways.

Throughout the rest of the day you'll hear from a wide variety of local businesswomen about attaining success, achieving your dreams and defining your future. The three conference tracks Connect, Learn & Grow and Lead are set up to align with the cornerstones of the AWTAustin organization. The cornerstones of the AWTAustin mandate are connect, learn, grow and lead. These are supported in the following manner:

Connect: AWTAustin events and conferences provide enlightening, motivational and fun networking opportunities for women in technology.

Learn: Through business and technology training such as lectures and discussions, we promote the enhancement of our members' capabilities and expertise.

Grow: Through thought leadership, mentoring and career resources we foster personal and career growth that helps members move into action, create change and inspire others as well as themselves.

Lead: AWTAustin creates opportunities that encourage members to gain a full picture of their leadership strengths and enable them to make a difference within their organization, family and community.

Attendees can choose from nine interactive and engaging sessions that fit with those themes. We'll wind up the conference with a Happy Hour where you'll have time to network, engage in a "Speed Coaching" session or just enjoy some refreshments and conversations with new and old friends.

Don't miss out... your future has never looked brighter and more exciting!
The Association for Women in Technology Austin (AWTAustin) is a not-for-profit organization comprised of women who work in, with, or have a passion for technology and who want to grow personally and professionally in order to make a lasting impact on our community.

If you would like more information about the conference, membership, or would like to sponsor our conference this year, please contact me – I would love to hear from you!

Brianna Barnes
AWTAustin 2007 Conference Chair and Marketing Coordinator at Seilevel

Policy as an influence on requirements

One source of requirements for a software system is business rules. Business rules are usually defined as rules and constraints that affect how a company achieves its goals. These rules are typically independent of the software system being designed or deployed.

But what about the collection of rules and constraints that are NOT independent of the software system being developed?

For example, suppose I'm automating my widget factory. I've got lots of equipment in my widget factory, and the software system that we'll deploy is going to automated all of this equipment, as well as the movement of widgets through that equipment. Because the automation aspects of the software system are completely new, there are few (if any) business rules that describe the constraints of the automated system. The managers of the factory need to make important decisions about how they want the automation system to operate. For example, they might need to make a decision about when they'll allow the automated system to shut down a piece of equipment without human intervention.

When I discuss this type of problem with customers, I typically describe it as a "policy" decision that they need to make. This type of decision is typically made by business managers rather than the technical subject matter experts who might describe the functionality of the system. Policy questions often answer "when" and "who" questions. They define "when" from a business management perspective we'll allow (or desire) certain things to happen. They define "who" (in some cases a system, in some cases a person) is allowed (or supposed) to do certain things.

There are several good reasons for calling out policies separately from other requirements:

1. Policies are often set by management. Management may not care about the operational details of a system that might be called out in a Software Requirements Specification, but they probably care very strongly about a specific list of operational policies.
2. Because policies are set by management, subject matter experts have often internalized the policies to the extent that they don't think about them. But during the requirements phase, we need to do a critical analysis of the entire system.
3. Policies are subject to change, and often affect many aspects of the system. By calling out the policies separately, you can trace the affects of that policy to other requirements.

There are some formal systems that have good hooks for policies. In IDEF terminology, a policy would probably act as a "control" on a function. There is definitely room for more research in this area.

Day 2 IEEE 14th Annual Requirements Engineering Conference

Ok, so I am finally getting around to post about day 2 of the requirements conference. Business has been great lately and so we have all had our noses to the grindstone but I finally found a spare moment to get these out.

RE06 was definitely an eye opening experience to me as I mentioned in my last post. The gap between academia and industry is like the gulf between the middle east and the west. On day 1 I went to a number of talks that were extremely technical in nature and it was hard to see how the research could be applied to real world problems. In discussing the conference with practitioners, they were in strong agreement. Therefore on day 2 I decided to attend the industry talks.

At the keynote on Day 2, Dorothy Graham talked about “Testing to Improve Requirements - Mission Impossible?” .

According to Graham, the fundamental questions about the relationship between requirements and testing are how do you develop tests from the requirements and when do you develop tests from the requirements. She discussed the V-model which describes development activities down the left side of the V and test/verification up the right side. For every activity on the design side, there is a corresponding test activity on the verification side. Her experience is that the very act of test design improves the requirements by forcing people to think about the requirements in a different way.

She gave two projects in contrast as examples. In the first project the team developed for 2 months then tested for 2 months with the test cases defined at the end of the process. This resulted in 150 faults discovered during test and 50 faults discovered in the first month of deployment. This was an extremely poor result. In phase 2 the team took a different approach, They took 2 months for development and 6 weeks for testing, with the tests designed upfront. The result was that there were only 50 faults found during the test cycle and no faults found in the first month. Now fans of Test Driven Development this may be a no brainer, but this is actually something slightly different in that the developers are working to tests created by the test team vs. unit/system tests created by the developers.

The essence of why this works is that the developers and product managers can effectively test the system during the whole project rather than at the end.

I then attended the invited experience talks. Ivy Hooks discussed "Requirements Engineering, an Oxymoron". The question that she asked was whether it was even possible to Engineer requirements or whether the nature of requirements was such that it was more art the engineering. Ivy emphasized that when gathering requirements, don't get the requirements from stakeholders because they are often emotionally attached to features that have no use to the actual users. Ivy's opinion seemed to be that while some process can be applied to requirements, the very nature of the activity is not engineering.

The last session I attended was the most interesting. It was a "birds of a feather session" to discuss requirements nomenclature. We had been working on nomenclature for the few months before RE 06, internally we had decided that non-functional requirements wasn't a very useful term, we had defined what we really mean by requirements vs. design, business rules etc. Many of the attendees were some of the most famous people in the academic and industrial requirements world so I was very excited to learn what the standard terminology was from the leaders. What I actually learned was that apparently none of them could agree on what the standard terminology is. If you find that you are confused about requirements terminology, don't feel bad because even the experts can't agree on the meaning of the most common requirements words!

At the end of day 2 I left feeling great about where we are at. At Seilevel we are constantly trying to push our understanding of requirements but we did not have a good feel for what state of the art really was. We now understand that our methods really are novel for the industry and we will keep pushing the limits to create more complete and easier to use requirements.

Stay tuned for day 3 (hopefully before Jan 1)

Managing Personal Scope

The nature of our work contributes to long hours and a hectic pace on projects. Our culture promotes work/life balance and “normal” work week hours. How does a company resolve these seemingly contradictory objectives? We manage what I like to call “personal scope”. Personal scope comes in two formats: I have too many individual tasks on my list and I can’t get them all done; and I have one task but to accomplish the task by the deadline I would have to work around the clock. Most of us have experience with the first personal scope situation and have developed our own styles and methodologies for handling it. Make a list. Order the list by importance. The items at the bottom can wait for another day or be passed to someone else. The second personal scope situation is harder.

Let’s say company X wants to build the Empire State building and has hired Seilevel to write the requirements documents. Monday morning consultant Bob shows up to kick off the project. The customer contact tells Bob, “We have to have the document by Friday for the contractors.” Bob may protest. He may make excellent arguments for why that’s not possible. But, in the end, the customer is always right. Bob must produce something to meet the customer’s needs in 5 days. How can Bob produce requirements the customer will find valuable and complete and still only work 40 – 45 hours this week?

Bob, can take a lesson from a May blog post called “The Magic of 7 – 9” (http://requirements.seilevel.com/blog/2006/05/magic-of-7-9.html) to ensure he adds value for the customer and doesn’t work himself into the hospital. The customer has indicated he needs a requirements document by Friday. Clearly the requirements for the Empire State building cannot be completely written by Friday. However, Bob should be able to define all the areas in which requirements will be needed and then further segment those high level areas into features and then requirements. Let’s explore this method of working normal hours and accomplishing a tremendous amount of value-add for the customer.

Bob realizes he can’t start asking all the stakeholders what’s important about the project without some methodology for capturing the information in a way that he can make sense of it quickly and effectively. Bob decides to take a first pass before he meets with anyone. Let’s brainstorm 7 – 9 areas in which Bob may need requirements. First, we look outside the building. Perhaps he will have requirements about what the building looks like, the parking, the safety features, the regulartory requirements, and the landscaping. On the inside, the document may need requirements that cover the layout and physical terrain, the environment and ergonomics, and the ambience / style imparted to a visitor.

Bob now has a list of 8 high level categories in which he must provide requirements to consider the document complete. At this stage, Bob has established the realm in which he will work. As he begins his first round of interviews to gather requirements he can categorize everything his stakeholders say to determine if he has good categories. He can also use his categories to remind the customer of areas he/she may not have thought of yet. Next, Bob schedules his first round of interviews. He meets with several stakeholders over the course of Monday and Tuesday. He now has mountains of information capturing ideas the stakeholders have about the building.

Bob can take his next cut using the 7 – 9 principle. In each high level category he identified he can take a look at the interview feedback and start selecting 7 – 9 features for that category. Let’s take the category ambience. Based on his interviews, Bob knows that many stakeholders want the building to feel warm, inviting, and rich, much like a law firm might. Bob thinks about places he has visited with this kind of ambience and the kinds of things that affect it: lighting, colors, materials, furniture, and wall decorations. He now has 5 sub-categories for ambience. Once he has fleshed out the sub-categories for each high level category, Bob may discover he’s ready to start writing requirements. He may discover he needs another level of specification.

The reason this approach helps Bob control his hours is he can stop at any level and he has a complete document. He has covered all the areas in which requirements may be defined to the specificity he can within his time frame. Bob has chosen breadth over depth. In a short timeframe, breadth has to come first. Bob may not have the final level of detail needed to build the Empire State Building, but he has added value by giving the customer a frame work around which requirements can be gathered. He has given the customer a document that speaks for itself in terms of next steps. Essentially, Bob has written the cliff notes of the requirements for this project.

Bob will probably have to continue digging deeper into each category, sub-category, and feature until he gets the final requirements documented. However, an approach that treats requirements like an onion, peeling back one layer at a time, rather than digging to the deepest level on one item and then moving to the next item, gives Bob the ability to control the scope he takes on each week. At any point in time, Bob can turn in a “complete” document. It may not be final. It may not be as detailed as Bob’s personal standards require. But it will be complete and will add value for the customer.

Goal-Oriented Requirements

This thread is going to be about Goal Oriented techniques. There's been some good academic work in this area -- you could look up Goal-Oriented Requirements Engineering (GORE) -- and some successes in practice. I've been following this area for about 10 years, and have used it for a few engagements.

I think the concepts are really interesting, and that it could be a useful addition to our modeling toolbox. But it's not a panacea at all -- it can become top-heavy if you document everything, and there are some other issues that arise in practical use. For one thing, there aren't many software packages that support this methodology (although there is a new entrant that's pretty good.) For another, multiple syntaxes for expressing goals and their relationships have been developed by academics, and a winner hasn't yet emerged. So in addition to looking at the strengths and benefits of goal orientation, I'd like to examine when it's appropriate to use, and how to best avoid or handle its limitations.

I'm going to start by commenting on a blog post I read this morning.It was from an agile software practitioner who had been to our seminar in February to the IEEE: "Getting beyond 'The System shall.....' ." (His blog is called A Random Blog, and can be found here --> http://speakercity.blogspot.com/2006...sentation.html.)

He disagreed with just about everything we said in the seminar -- but at least he was listening! ;-) Someday (in the far distant future when I have the time,) I'd like to answer each of his points, because he got me all riled up. But for now I'll just speak to a couple of things he said:

"As Seilevel states they are in the business of 'creating requirements documents.' I think this whole mission is just missing the bigger picture. No one cares about better requirements documents, people want better software products..... the requirements document is not an end goal."

Well, sure. But you could also say that about languages, and compilers, and test plans, and development methodologies, and all the other tools and techniques we use to tame the wild beasts of software. I suppose he said it because agile folks like to dive right in. And that can be a lot of fun out of the box, and it's great when it works. (Not so great when it doesn't, but that's not on topic.) Anyway, we think that specializing in this specific part of the development cycle is important, because there's a lot more to getting to the right requirements than at first it might appear -- and our clients agree, or else they wouldn't use us!

Another issue he raised was the use of models, which he thinks inappropriately stray into the realm of design. As we know there is an intimate relationship between requirements and design that increases as constraints on the solution are identified. As a simplified example, let's say the requirement is to get people from New York to Washington, D.C. faster. We could build a superhighway or we could build a high-speed train track. If the decision is for high-speed trains, then do we build a super-flat and strong base for the rails, so that the train won't bump and sway (or derail) when it hits speeds of 150+ mph? Or do we build a mag-lev system? The requirements for each would vary greatly, and as the funding authority made decisions on exact technologies, the requirements would become more and more detailed, until finally we come to "a laser calibration system for measuring the variation of rail placement from specs, with an automated system for generating work orders." And then we plunge further into that.

At each level a requirement can be seen either as a constraint on possible design solutions, or in itself as an element of a design solution to a requirement from the "next higher" conceptual level. In this sense a requirement has a dual nature. As an element of a design solution to a higher-level requirement, a requirement is a "satisfier" of a goal implicit (or expressed) in the higher level. And in turn it implicitly or explicitly expresses a sub-goal for the next lower level to hopefully satisfy.

So from this perspective any requirement has two components that are both needed, although one or the other might be implicit -- a goal component and a constraint component. So a requirement has a dual nature twice! (Anyway, that's my proposition for you to consider.)

(BTW, there is a big area of research in the AI field where truth is defined through "constraint propagation." It's used for visual scene recognition, scheduling, and a lot of other things. Google it if you're interested in that area. (Maybe someday we could steal some of those algorithms and apply them to requirements? I have no idea if that would work or not.))

Because of the goal/sub-goal relationships, most of the methodologies tend to show examples of hierarchical structures. But the real world is more complex than that - often goal trees are not enough, and inter-connected goal webs have more fidelity.

That's all for now. Let me know if you want to hear any more on this subject, OK?

Happy New Year, it’s time to set your vision

Instead of New Year’s resolutions, I have chosen to set an annual theme for each year. Though the topic is a bit outside the requirements space, I’m going to share the concept here, as it is very much like setting a vision for an organization.

The idea behind setting New Year’s resolutions is to focus on self improvement. Organizations take on new projects for the very same reason, to grow the organization in alignment with their vision.

I like the idea of New Year’s resolutions, but typically they turn into frustrating experiences because we set some goals, work really hard on them for a couple months, and then forget them completely. I think the critical thing missing from this effort is an overall personal vision for the year.

In an organization, a vision helps the team understand the direction the organization is growing. It helps motivate the team, guides their choices and directs changes when off course.

Similarly, an annual theme is a simple idea or phrase that explains your focus for the year. You can think of it as a summary phrase that encompasses a goal or two that you want to set. As the year progresses, I use my theme to guide my choices and notice when I’ve gone astray. To illustrate the concept, I’ll give a few personal examples.

A couple years ago, I set an annual theme of “joy”. In years prior, I had some life changing events that highlighted how I had lost touch with my own identity and a sense of happiness. I set a theme, playing off my name, for my intention to figure out who I was and to do the things that were simply fun to me. With “joy” as a focus for the year, I ended up taking up a new hobby with triathlons. I took the most amazing trip of my life...alone. I also got much better at making choices based on what I wanted instead of what the people around me would want me to do.

After outstanding successes, the following year I tried a new theme of “trust the gut”, inspired by Blink. Again, looking to the past in picking the theme, I could see that most unhappy times for me were a direct result of over thinking and ignoring my gut reactions to situations. I set a theme for noticing my initial reaction and explicitly choosing to follow it (or ignore it and notice how that played out!). For example, I could think through a detailed decision tree for a conversation with a customer or co-worker, consider all the paths it could take and be ready to follow the path in real-time. However I have created some of the strongest relationships with a simple effort to not over-think conversations, but rather follow my gut to navigate them. Looking back at that year, I can see that the times I was most unhappy standout as situations where I ignored my gut reaction.

If you are interested in trying the annual theme concept, here is how:
1. Pick your theme – look at the previous year to see what stands out the most in terms of what you liked and did not like.
2. Solidify the intentions for your theme - think about what the theme means to you, why you are choosing it and what you want to get out of it.
3. Set a simple phrase for the theme – come up with one to three words that will be easy for you to remember.
4. Use your theme!

There is no right or wrong way to use your theme. By simply having one and setting the intention to use it, then you will find at different times you proactively apply it, passively apply it and even forget to apply it. All of these are great – the key is it is just a theme, guiding you through life.

Setting a single annual theme for your year can be a less frustrating and much more rewarding experience than the typical New Year’s resolutions.