Wiki Home

Software Requirements


Namespace: Wiki
A Wednesday Night Lecture, held 2001.01.24
This session was based on the powerpoint presentation available at:
www.eps-software.com/training/reqIntro.htm

[Irrelevant material has been trimmed]

[20:46] *** Topic is 'Software Requirements with Ellen Whitney'

[21:01] {Evan Delay} The speaker tonight is Ellen Whitney. Ellen is a Visual Studio Developer and part owner of EpsSoftware in Houston, Texas. She specializes in object oriented design in VFP and has been working with FoxPro since 1991. She is also the Managing Editor for CoDe Magazine.

[21:02] {EllenWhitney} OK, today's lecture will be based on a .ppt presentation that I've posted to www.eps-software.com/training/reqIntro.htm.

[21:06] {EllenWhitney} [3]

[21:06] {EllenWhitney} In this session we'll talk about the basics of requirements. It's really not as boring as it first seems.... Actually, I'm starting to almost enjoy the process.... (well, ALMOST) :)

[3] Session Overview

  • What are software requirements?
  • Why are requirements important?
  • How to track requirements

    [21:07] {EllenWhitney} [4]

    [21:08] {EllenWhitney} Software requirements really boil down to the tasks that the software must perform and HOW it performs these tasks
    look & feel, operating system, COM, XML, Web etc)

    [4] What are Software Requirements?

  • The tasks that the software must perform
  • Business Logic POV (the business rules behind the program, WHAT the program must do)
  • How it will perform the tasks
  • Technical/Non-Business point of view (HOW – speed, look & feel, operating system, COM, XML, Web etc)

    [21:09] {EllenWhitney} [5]

    [21:09] {EllenWhitney} Requirements are unquestionly important. Obviously, without good requirements, there is NO WAY you are going to build good software.

    [21:10] {EllenWhitney} This lecture is based on several books I've read lately.

    [5] Software Requirements by Karl E. Wiegers

  • “40 – 60% of all defects found in a software project can be traced back to errors made while gathering information”
  • Typical outcome of incomplete requirements is a huge gap between what the developers think they are supposed to build and what the users think they will get

    [21:11] {EllenWhitney} [6]

    [21:11] {EllenWhitney} Here are some reasons why Req are important....

    [21:12] {EllenWhitney} The last one - "Makes it difficult to plan and estimate the project accurately" benefits us from a developer standpoint as much as it benefits the customer.

    [6] Why are requirements important?

  • Software doesn’t function properly
  • Won’t allow users to do their job
  • This increases development time which increases the overall cost of the project
  • Makes it difficult to plan and estimate the project accurately

    [21:14] {EllenWhitney} [7]

    [21:14] {EllenWhitney} Creating software w/o good requirements is like me going to an architect and asking him to build me

    [21:14] {EllenWhitney} "a nice, big house for under $200,000"

    [21:14] {EllenWhitney} He could do it, but it's highly unlikely it would be exactly what I had in mind....

    [21:15] {EllenWhitney} Hi Denis - yes the "n" and "u" are supposed to be bullets....

    [21:15] {EllenWhitney} Unfortunately, they don't show up right on everyone's browsers.... I'm not sure why.

    [7] Example

  • Creating Software without requirements are like trying to build a house without a blueprint or specs
  • “a nice house”
  • “a big house”
  • “$200,000 budget”

    [21:15] {EllenWhitney} [8]

    [21:15] {EllenWhitney} OK, here's where the terminology starts to get confusing....

    [21:16] {EllenWhitney} In different books, different authors refer to the TYPES of requirments differently

    [21:16] {EllenWhitney} What is referred to as "functional" in one book is considered "non-functional" in another....

    [21:17] {EllenWhitney} But basically, I consider "Functional" to mean the WHAT the product must do

    [21:17] {EllenWhitney} and "Non-Functional" to mean the "look and feel and the technology behind it"

    [8] Types of Requirements

  • Functional Requirements
  • The functionality of the product
  • Non - Functional Requirements
  • The product’s qualities
  • (often there will be overlap and/or conflicts between the various types of requirements)

    [21:18] {EllenWhitney} [9]

    [21:18] {EllenWhitney} So Functional Requirements mostly deal w/the business rules.

    [9] Functional Requirements

  • Scope – defines the product boundaries, and it’s connections to adjacent systems
  • Business Rules – the rules that the system must conform to based on the individual business. Also includes the data that must be tracked. (most important and most of your requirements will be this type)

    [21:19] {EllenWhitney} [10]

    [21:20] {EllenWhitney} As I said before, the Non-Functional Req deal more with the "LOOK" and "FEEL" of the software. I also consider the technology used to be part of the "Non-Functional" requirements.

    [10] Non - Functional Requirements

  • Look & Feel – the intended appearance
  • Usability – based on intended users
  • Performance – how big, fast, reliable etc.

    [21:21] {EllenWhitney} [11]

    [21:21] {EllenWhitney} Non-Functional can also cover a lot of other areas too....

    [11] Non - Functional Requirements (cont)

  • Operational – product’s intended operating environment
  • Maintainability & Portability – how product will evolve over time
  • Security – user access in the product

    [21:22] {EllenWhitney} Here are two types of N.F. requirements that are sometimes overlooked. Often times there are things in our software that occur because of political reasons. Not because they may be the BEST way to do something, but because it makes the client happy. :)

    [21:23] {RandyJean} Those can bite you, let me tell you ;-]

    [21:23] {NancyFolsom} < sigh >

    [12] Non - Functional Requirements (cont)

  • Cultural & Political – human factors
  • Legal Requirements – conformance to applicable laws

    [21:23] {EllenWhitney} [13]

    [21:23] {EllenWhitney} As I said before, different sources name different types of requirements differently. But this is really not very important. It's much more important to make sure that you collect ALL the requirements and don't worry too much about what TYPE they are.

    [21:24] {CarlKarsten} What do you mean by "type"?

    [21:25] {EllenWhitney} Carl - Type = Functional vs. Non-Functional

    [21:25] {CarlKarsten} Got it

    [21:25] {EllenWhitney} Another important point is that while you are finding out all the requirements focus on WHAT the requirments are. Don't worry about the technology that you will use to accomplish them. If you think about the technology up front, you run the risk of limiting the software. You will always have time later to eliminate or scale back.

    [13] Note!!

  • Different sources(books etc) have different (and sometimes conflicting) names for the various types of requirements.
  • Collecting all the requirements is much more important than what “category” they fall into
  • While you are collecting the business requirements ignore the technical aspects of the program. Focus on WHAT, not HOW.

    [21:26] {EllenWhitney} [14]

    [21:27] {EllenWhitney} These are mostly common sense....

    [21:27] {CarlKarsten} I think Necessary needs some clairifaction

    [21:27] {EllenWhitney} Obviously the requirements much be accurate.

    [21:27] {EllenWhitney} Necessary means that it really is a business rule (for example).

    [21:28] {EllenWhitney} Make sure that it's a true requirement of the business process and not just a restriction because of the current way someone is doing their job.

    [21:28] {CarlKarsten} Exactly

    [21:28] {EllenWhitney} Verifiable is also important. You should be thinking of ways that you will know when you have programmed something successfully. How to know when it has fully met the criteria.

    [14] Good requirements are:

  • Complete
  • Correct
  • Feasible
  • Necessary
  • Prioritized
  • Unambiguous
  • Verifiable (through observation and testing)

    [21:29] {EllenWhitney} [15]

    [21:29] {EllenWhitney} One of the methods that one of the books suggests is to create a single checkpoint that all the requirements must pass thru.

    [21:30] {BarbaraPeisch} define "checkpoint"

    [21:30] {EllenWhitney} This makes it less likely that you will end up with some 'bogus' requirements.

    [21:30] {EllenWhitney} What I mean by "checkpoint" is to have a single person (or group of people maybe in a large project) that review and approve ALL the requirements.

    [15] Quality!

  • Create a checkpoint where every requirement must be approved by a single person/group of people. Especially important in a large project.
  • Make sure that the requirements contain enough detail.

    [21:31] {EllenWhitney} [16]

    [21:31] {CarlKarsten} checkpoint = person ?

    [21:31] {EllenWhitney} Carl - yes

    [21:31] {EllenWhitney} OK, when you are collecting the req. you will probably have multiple sources. Domain Experts I believe are the crucial people in any software project. These are people that understand their business. If you are really lucky, you will end up with a Domain Expert who also was a User at some point. To me, this is the best possible scenario.

    [21:33] {CarlKarsten} I got bit by having a DomainExpert that wans't - I found out all the 'extra' requirements way later

    [21:33] {EllenWhitney} Carl - Well, yes that of course is something to be aware of.

    [21:34] {BarbaraPeisch} Carl, that's why you need to cya and get the requirements in writing.

    [21:34] {RandyJean} Happens to me all the time < g >

    [21:34] {EllenWhitney} It's sometimes difficult to judge since you are the "newbie" person (probably) to that particular business.

    [21:34] {Evan Delay} Hopefully the domain expert has authority as welll.

    [21:34] {EllenWhitney} Another good resource for gathering req's. is existing software and also existing manual processes.

    [21:35] {RandyJean} Evan - you hit the nail on the head. Gotta get past the poser DE somehow.

    [21:35] {EllenWhitney} Find out what the users like/don't like about their current system. Find out where all their time is spent.

    [21:35] {BarbaraPaltiel} And sometimes you run into 'office politics' between Domain Users.

    [21:36] {EllenWhitney} Always be on the lookout for the possibility of automating a currently manual process. Also take a look and see if there is any similar software out there. You can often get good ideas about things to add (or NOT to add < s > in your program.

    [16] Resources

  • Domain Experts
  • Users
  • Existing processes/programs
  • Find out limitations of existing systems and software
  • Find out where all the user’s time is spent
  • Find out what they like/don’t like
  • Sit down w/them WHILE they are performing their tasks. Ask questions!
  • Similar software programs

    [21:37] {EllenWhitney} [17]

    [21:37] {NancyFolsom} But be ware of relying too much on an existing app for your "requirements." I've been bitten where it turned out the clients hated the existing stuff but were mad if the new system didn't do things the same way.

    [21:37] {EllenWhitney} OK. Here are a list of different methodologies for collecting requirements. There may be others also.

    [21:38] {CarlKarsten} Snow Cards?

    [21:38] {EllenWhitney} Carl - Yes, we'll get to them in more detail....

    [17] Techniques for Collecting Requirements

  • Cards
  • CRC Cards
  • Volere “Snow Cards”
  • XP “Story Cards”
  • Templates
  • Vision and Scope Document
  • Volere Spec
  • Requirements Trace Matrix
  • (combination is probably best depending on where you are in the process)

    [21:38] {EllenWhitney} [18]

    [21:39] {EllenWhitney} Using "cards" (index cards) are very "low tech" but have some good benefits, especially early in the process.

    [18] Cards

  • Allows easy way to group, reorganize, discard
  • Fast way to jot down ideas
  • Can easily be distributed to different people/groups
  • Excellent for starting the process

    [21:39] {EllenWhitney} [19]

    [21:40] {EllenWhitney} Templates are like outlines. They help you make sure you address all the important elements of the development process.

    [21:40] {NancyFolsom} El-Do you have good source of templates?

    [21:40] {EllenWhitney} Nancy - Yes, we'll get to that.... :)

    [21:40] {DenisChasse} Could you expand on Protects against scope creep?

    [21:40] {EllenWhitney} Denis - If you have good requirements, the entire scope of your project has been discussed with your client. You and your client both understand (based on the requirements list) the entire scope that your program will cover. This way, the client realizes that if later they think of a new requirement, it is in ADDITION to what was already agreed on. This means it will take more time to complete than you estimated, and will cost more money. Having written requirments protects you from "Just one more LITTTLE thing..." :)

    [19] Templates

  • Collects all the business requirements into a single concise document that sets the stage for the entire project
  • Insures that everyone involved understand the project
  • Protects against scope creep

    [21:43] {EllenWhitney} [20]

    [21:43] {EllenWhitney} The Requirements Trace Matrix is simply keeping the important items about the requirements in a tabular format. This is more useful later in the process when you have things more organized.

    [20] Requirements Trace Matrix

  • Grid keeps things organized/detailed
  • Allows easy way to link to the Use Cases
  • Good in the later part of the requirements process

    [21:44] {EllenWhitney} [21]

    [21:44] {EllenWhitney} Using CRC cards is an old techique. It stands for Class/Responsibility/Collaboration.

    [21] CRC Cards

  • Class – “nouns”, collection of similar objects
  • Responsibility – Anything the class knows or does.
  • Collaboration – Occurs when the class needs information that it doesn’t have.
  • Low tech – use cards or flip chart paper

    [21:45] {EllenWhitney} [22]

    [21:46] {EllenWhitney} The Volere "Snow Cards" are very similar. They are preprinted cards that the developer fills out as they are collecting the req's.

    [21:47] {BarbaraPeisch} What is that "Customer Satisfaction/Dissatisfaction" item about? Is it with the existing system?

    [21:47] {EllenWhitney} Later in the lecture, I'll give you some URL's and book titles that have more info on these techniques.

    [21:47] {EllenWhitney} Barbara - Yes.

    [22] Volere “Snow Cards”

  • Requirement Number
  • Requirement Type
  • Event/Use Case #
  • Description
  • Rationale
  • Source
  • Fit Criterion
  • Customer Satisfaction/Dissatisfaction
  • Dependencies
  • Conflicts
  • Supporting Materials
  • History

    [21:47] {EllenWhitney} [23]

    [21:47] {EllenWhitney} XP stands for "Extreme Programming." XP is a whole other topic, but the requirements gathering consist of collecting "stories." Some of you will love this... the DEVELOPER doesn't write the "stories", the CUSTOMER does! :)

    [21:49] {RandyJean} I like it already!

    [21:49] {EllenWhitney} Personally, I have to say, I don't really use any of the "Card" methods.

    [21:49] {BarbaraPeisch} Yeah, but what you get back may be unintelligible.

    [21:49] {DenisChasse} Does he write the app too ? :-D

    [21:49] {EllenWhitney} I prefer the templates and then the Requirements Trace Matrix.

    [21:49] {RandyJean} I know 1 client that I might actually get something usable from this way < g >

    [21:50] {EllenWhitney} Barb - Well, the develper DOES have to read and understand and talk to the customer... :)

    [21:50] {BarbaraPeisch} Aw, you mean I have to do some work after all? < bg >

    [21:50] {EllenWhitney} Denis - are you trying to put yourself out of a job? < BG >

    [23] XP “Story Cards”

  • Simple “stories” – a few sentences
  • Each story would take a programmer less than a week to complete.
  • Written by the customer

    [21:50] {EllenWhitney} [24]

    [21:50] {EllenWhitney} OK, the templates. This is what we use at EPS. We don't use any of these EXACT ones that I will be talking about, but more of a combination of all of them.

    [24] Vision and Scope Document

  • Vision
  • What the project encompasses and what the product could ultimately become in the perfect world
  • Scope
  • Reality of what the project will include
  • Priorities

    [21:52] {EllenWhitney} [25]

    [21:53] {EllenWhitney} The Vision and Scope Document is simply an outline that the developer (sorry Randy) fills out w/the help of the customer. The major sections include the items shown in slide 25. I will give you the name of a book later that covers this in great detail.

    [25] Vision and Scope Document (cont)

  • Business Requirements
  • Vision of the Solution
  • Scope and Limitations
  • Business Context
  • Product Success Factors

    [21:53] {EllenWhitney} [26]

    [21:54] {EllenWhitney} The Volere Spec is just another form of template. If you go to the URL that I have listed there, it has the template available w/detailed descriptions of each section

    [21:55] {NancyFolsom} Cool resource!

    [26] Volere Spec

  • Product Constraints
  • Functional Requirements
  • Non - Functional Requirements
  • Project Issues
  • See (http://www.atlsysguild.com/guildsite/Robs/Template.html)

    [21:56] {EllenWhitney} [27]

    [21:57] {EllenWhitney} As I said before, the Requirements Trace Matrix is really something that is good later in the process. Once you have gathered most of the requirements and need a way to organize them better and to move onto the next step - the Use Cases.

    [21:58] {EllenWhitney} Assuming Evan wants me back, I'll be doing a Use Case lecture in a few weeks.

    [21:58] {Evan Delay} Yes!

    [27] Requirements Trace Matrix

  • Entry Number
  • Paragraph Number (from other docs)
  • Specification/Requirement
  • Type (SW/HW/derived, nice-to-have)
  • Build
  • Use Case Name
  • Class
  • Method

    [21:58] {EllenWhitney} [28]

    [21:58] {EllenWhitney} OK, now we get to some cool stuff. There are programs out there to help you track requirements. One that we use at EPS is Steven Black's Wiki.

    [21:59] {EllenWhitney} I guess you guys probably are all familiar w/the Wiki right? The Wiki is a really GREAT way to keep track of Requirements because of the automatic linking features and because it's accessible from the Web. This means that at EPS in Houston we can be working on our requirements w/our client in California. You can actually buy the software that runs the Wiki from Steve and host it on your own server or you can have him host a private Wiki site for you. (Gee, maybe I should ask Steve for a cut if he sells any in the near future....) :)

    [21:02] {Evan Delay} We found the wiki great as a collaboration tool for the exam study groups.

    [21:02] {EllenWhitney} We use our own private Wikis for all our Project Management. There are also products by Rational Rose, but of course they are expensive. I have never personally used them to be honest.

    [21:03] {EllenWhitney} The last item is a link to a list of various tools. There is one more item that I don't have on the list. It is from Harold Chattaway, the VFP guy who wrote bugcentral (www.bugcentral.com). He says "The site will be called RequirementsCentral.com. It will be part of the portal site softwarelifecycle.com You can check the latter site out now, to see what we are offering. Requirementscentral.com is reserved, but not up yet." He plans on having it up and running in June. If his RequirmentsCentral is as good as Bug Central, I'd highly recommend it. Plus you are supporting a fellow VFPer. :)

    [28] Requirements Software Tools

  • Wiki (contact steveb@stevenblack.com) wikis.com/wc.dll?Wikis~Wikis.Com
  • Rational Products (www.rational.com/products/sysdef.jspReq)
  • Rational Requisite Pro
  • Rational Suite Analysts Studio
  • Misc List www.atlsysguild.com/GuildSite/Robs/retools.html

    [21:05] {EllenWhitney} [29]

    [21:05] {EllenWhitney} Here is a list of books that I would recommend. Personally the Mastering the Requirements Process is my favorite of the 3...

    [21:06] {Evan Delay} Egger has a good chapter on requirements too.

    [21:06] {EllenWhitney} And it seems to more closely follow the UML language. Markus' book is Advanced Object Oriented Programming with VFP6. It's available from www.hentzenwerke.com.

    [29] Recommended Reading

  • Software Requirements by Karl Wiegers
  • Mastering the Requirements Process by Suzanne and James Robertson
  • Extreme Programming Installed by Jefferies, Anderson, Hendrickson

    [21:08] {EllenWhitney} [30]

    [21:08] {EllenWhitney} There are some training classes on requirements. I can't personally endorse any of them, since I've never attended, but I thought it was worth noting.

    [21:09] {EllenWhitney} There is one more seminar that I got in today's mail. You can get more info at www.dciseminars.com. I only visited the site briefly, but the M$ one looks pretty good.

    [21:10] {EllenWhitney} Also, Construx is the company that Steve McConnell works for. He has written some really good books, so I'm sure his seminars would be good also.

    [30] Workshops/Training

  • Microsoft http://msdn.microsoft.com/msdn-online/training/courseware/1585.asp
  • Construx Steve McConnell, www.construx.com
  • The Knowledge Exchange Company www.tkec.com/facilitated-sessions-jad-training.htm

    [21:11] {EllenWhitney} [31]

    [21:12] {EllenWhitney} In the Spring 2001 issue of CoDe Magazine, I will be writing an article about Requirements. Nancy and Barbara's column will also tackle the subject of Requirements and how to work with your customer to make sure good requirements are gathered.

    [21:12] {RandyJean} I've got the New Rider's study guide for the requirements part of the MCSD exam. It's pretty good so far. about $50 at Border's

    [31] More Information

  • Spring 2001 issue of CoDe Magazine (due out in May 2001) (www.code-magazine.com)
  • Nancy and Barbara’s Column

    [21:13] {EllenWhitney} [32]

    [21:13] {EllenWhitney} Summary. In case you fell asleep - here's what you missed! :)

    [32] Summary

  • Two main types of Requirements
  • Functional Requirements
  • Scope
  • Business Logic
  • Non - Functional Requirements
  • Look & Feel
  • Performance
  • Technical Requirments
  • Type not really important as long as ALL requirements are gathered!

    [21:13] {EllenWhitney} [33]

    [21:13] {EllenWhitney} Whew. Any questions?

    [21:14] {Evan Delay} Can you give an example of the XP stories?

    [21:14] {EllenWhitney} Sure...

    [21:14] {RandyJean} REPLICATE("Applause!",50)

    [21:14] {TheressaMetcalf} hehe

    [21:15] {EllenWhitney} "When a transaction causes a customer's account to go into overdraft, transfer money from the overdraft protection account, if any"

    [21:15] {DenisChasse} Thank you Ellen!

    [21:15] {EllenWhitney} Right from the XP book page 25. :)

    [33] Q & A

  • Feel free to email me:ellen@eps-software.com
  • Visit us on the web: www.eps-software.com
    Contributors: EllenWhitney, Evan Delay, Cindy Winegarden

    Category Wednesday Night Lectures
  • ( Topic last updated: 2001.01.30 03:47:54 PM )