Software Requirements and Spec
Software Requirements and Spec CSSE 371
Popular in Course
Popular in Computer Science and Engineering
This 41 page Class Notes was uploaded by Miss Terry Reichel on Monday October 19, 2015. The Class Notes belongs to CSSE 371 at Rose-Hulman Institute of Technology taught by Staff in Fall. Since its upload, it has received 7 views. For similar materials see /class/225099/csse-371-rose-hulman-institute-of-technology in Computer Science and Engineering at Rose-Hulman Institute of Technology.
Reviews for Software Requirements and Spec
Report this Material
What is Karma?
Karma is the currency of StudySoup.
You can buy or earn more Karma at anytime and redeem it for class notes, study guides, flashcards, and more!
Date Created: 10/19/15
Here they are Objective Mess Purpose To single out a goal or objective and set its priority Outcome Decision to solve using CPS and reasons for doing so Goal FACT Finding To get a better understanding of the mess or objective To identify chaHenges More informa tion enabling a clearer under standing and generating an initial problem statement PROBLEM Finding IDEA Finding SOLUTION Finding Purpose and Outcomes To broaden awareness of the problem and its sub problems Series of prob lem statements from which to choose the most opportune challenge to solve To generate answers to the problem state ment possible solutions Series of ideas or alternative actions that may solve the problem To select and evaluate from action alterna tives for fit One or more solutions to the problem selected from ideas or alternative actions previously generated ACCEPTANCE Finding To identify resources that will support the selected solution Listing of resources and action steps needed to sell and implement the selected solution Implementation To put into action the selected solution Action monitor and evaluate progress The CPS model quotquot39 7The Creative Problem Solving Process of Osborn Parnes 1993 version Showing lots and lots of diamonds moving from left to right Though the problem solving order really isn t any more sequential than say the way we follow the waterfall model in development And the process often is applied to just those steps where divergent as well as convergent thinking are most needed emeriocai votes Ramw erl x Annnm Work ere Archive Copyand Edit Work Use case map for theNetLeam project from Suthersusecasemgphtm l Elaboration of Use Cases CSSE 371 Software Requirements and Speci cation Steve Chenoweth RoseHulman Institute October 21 In the book This i 2004 sCh2526 What do use cases become Eventually like we see at the web site 39 le im39TuL J httpw1k1csu1uceducs497re1OHVIS M a cum KM WW DETAILEDUSECASES Jr qu mj Emma Malls Imus 0 Goal People can design from these W5 quot1quot quotmyquot How do they do that L One example From CRC Cards r Mms 7 9 See the Cal Poly tutorial at F5 httpwwwcsccalpolyedudbutlert HMquot 19399quot utorialswinter96crc b WWW 0PM Or Alistair Cockburn s tutorial at quotLush m Jami l httpalistaircockburnuscrystalarticl esucrccusingcrccardshtml CRC Class Responsibility Collaborator 2 This is Chapter 25 From Use Cases to Implementation Getting There What are the issues Sometimes it is easier to design and implement a system feature than others For instance if a feature mostly involves interaction between the software and one or more actors the use case events correspond well with the steps of the implementation algorithm However in other cases such as when quality Vi requirements or complex data structures are A involved the design does not follow as directly this is problem of orthogonality 9 You have to stir in use cases and those quality attribute scenarios 3 Getting There And the x for orthogonality An objecl 0 Some potential solutions don t we hope Objectoriented design 3 quotWW Wellwritten use cases Modeling the software architecture WW 0 The software architecture helps us understand what WWW the system does and how it works how the elements mn interact and what type of patterns and pieces or the system are involved 39 9 Example A typical 00 design process like CRC cards assumes you are running on a single processor without ever saying so 9 OO hides architectural problems along with other detail So we try to resolve some design issues with architecture The software architecture helps us understand what the system does and how it works how the elements interact and what type of patterns and pieces or the system are involved Architectural views Logical for users Implementation programmers Process integrators Deployment system engineers Usecase view designerstesters ties things together End User Functionality Programmer Software management Logical Implementation VIEW V Usecase View Process Deployment view View Figure 25 2 The 41 architectural view Deslgnerslfesters System Integrators Periormance System Engineering System topology Delivery Installation Communication Scalability Throughput 9 Likely test question What is Systems Engineering 2 answers One answer 7 See httpwwwrose w mm ed Class 11 HTMLCourseof f erino htm MG20587 5 When Tori1 was here on Tuesday She said We do the architecture rst then get requirements from the customers 9 Why would you develop software that way Illustration of 51mph CnmpulerAdlphve Tail ND Left 7 Architecture example from www hiofntn mm www quot 39 A com higheredapraccu html quot 39 quot Rightil 1 39 example from the dreaded 1Tori Bowman of Rockwell Collins RHIT CS grad June 2004 This is Chapter 26 From Use Cases to Test Cases Later in the development cvcle What about testing With use cases Validation test cases are ones that are performed from the user s pointof Vlew They are examples of blackbox test cases 0 Use cases are not exactly validation test cases although use cases do drive the process of validation test case generator 0 Steps in creating a test case Identify usecase scenarios Start use case Basic ow basic and alternate ows WWW Identify the test cases rrrrrrrrrrrrrrrr Bxfefffejfwf gggggg H Identify the test conditions Aquotquotquot equot i fmemnowsa Add data values to the test case End use CEIle Figure 26 2 Scenarios for a use case 9 You ll have a chance to try creating a few of these in HW 10 But not so fast Here are the basics Test Plan 0 Contains C Is source of n m 7 CC 77 1 There s a test plan for how to do these enerall Provides Inslructions for g Y 2 The use cases each 777777777777777777777777 become multlple test 1 n Automates execution of 1 1n Team Exeruse 5 mm Where 1n your term pro ect would you want lots of test Records resulrsof cases Test Results Figure 26 1 Relationships among test artifacts And how do you know 9 Read the rest of Ch 26 before you do HW 10 8 Problem statement for a Graduation Planning System use case brainstorming session See team meeting notes for 926 Added excluded from scope based on for cross reference with course to out scope removed students having the ability to give access to others removed teachers from additional features requested Summary of Primary Success Criteria I Storyboards are created and approved by the client I A working prototype is demonstrated and approved by the client I A user manual is created to articulate how the system will be used I Use cases are written and tested against the requirements with success Client described these use cases and working scenarios Scope The Graduation Planning System will allow current students and advisors to plan a course of study for any RoseHulman major and minor The system will be designed to show which classes must be taken during which quarter to graduate at a speci c time Additionally changes of maj ors and minors will be allowed and the system will show what impact these changes will have on the graduation date The system will be integrated with the existing RoseHulman Banner Web to allow students to register for online for the classes they have chosen Not included in the scope of this project are The application will not perform and scheduling functions Graduation planning for Master level students Perspective Rose Students will not be able to view a course of study Tools for advisors Tools for registrar student interest level alert for scheduling conflicts I Reporting by quarter year student status major professor class size class room Page I of 5 Project Team 5 Section I Bx lnyideoc Integration with financial aid office Ability to recognize courses that don39t count for overloading ROTC life skills Ability to be used as a forecasting tool for department heads in order to predict the number of sections required Ability to create adhoc reports Ability to see final test schedules Handling online web based courses 10 Function Key Business Features access to COUISC nam e on a separate screen Page 2 of 5 Project Team 5 Section I Bx lnyideoc Kev interfaces I Feature No I Feature Name I I Integration with banner I 20 Form Key attributes Performance and Capacity I The system should be stable be able to handle a load of 400 students registering simultaneously Constraint imposed by client I Schedules should be generated in less than 5 seconds and constraints should update the schedule within 5 seconds Constraint imposed by client Reliability and availability I The application should be available the majority of the time with only minimal time allowed for maintenance Downtime should be less than 1 hour per month I The system should be available when Banner Web is available except during scheduled maintenance periods Usability I Web based user interface similar to existing Banner Web system lLinimal graphics to allow for dial up users I The system will make use of color to distinguish between courses completed courses scheduled and fixed and technical area and free electives See feature 55 I The user will be allowed to use generic placeholders for classes such as humanities and technical electives so as not to have to pick a certain class See feature 59 Security I Secure entry using a user Kerberos name and password Constraint imposed by client Students will have access to their information only Advisors will have access to their advisees schedules which will be granted by area department heads Modifiability maintainability and customizability I The system will be developed in the RoseHulman standard development environment and will utilize object oriented and reusable code modules to allow modifications customization and support I System should be able to adapt to changing requirements majors and course offerings without extensive modification Testability I The system will be developed in a development environment separate from the testing and production environments to allow for regression and load testing to be performed I Test cases will be built from Uses Cases and Supplemental Specifications detail In the case of orthogonality use case rationalization will be use Page 3 of 5 Project Team 5 Section I Bx lnyideoc Hardware and Software Constraints Must be web based and developed in an application supported by the RoseHulman IT department Current softwarehardware include Microsoft Windows based operating systems and Oracle database and development environment The client has requested that specific features be designed using tools such as drop down boxes and separate screens See Features 57 58 60 Key Interfaces I Integrated with Banner Web through Oracle database calls Reguired Standards Will support the RoseHulman IT coding verification validation and user training installation and implementation support standards 30 Economy Business Context In the current climate several issues exist that the client would like to have removed for planning a student graduation strategy Freshman are not assigned a department but are randomly assigned an advisor When the student enters with several advance placement credits or declares a major outside of the advisors area it is difficult and cumbersome to think about long term graduation plans For this reason advisors usually only plan for the next quarter and have a hard time generating graduation dates for the occasional what if scenario of major and minor changes additions of majors and minors and skipping quarters Customer Organizational Constraints Students advisors and registrar users should have access to this application via secure entry over the World Wide Web Basic browser skills will be necessary to use the application Students and their advisors will automatically have permission to students information This application will not interface with Banner Web to allow for scheduling Therefore a course may be recommended by the application that is full The student will manually have to remove this course when heshe becomes aware of this conflict Development Organizational Constraints Students will develop the application and therefore access to live student records must be prevented The students are expected to have the software development life cycle skills necessary to complete the project Key Risks and Uncertainty I Scope creep in key features The team will mitigate by meeting with the client weekly and reviewing use cases and GUI s to get quick feedback and negotiate release features I Longterm support costs It is expected that this project will have a budget that includes at least the following I Development Costs by manhours for Discovery Development Quality Assurance User testing Training and minimal post implementation support I Annualized first year maintenance costs Page 4 of 5 Project Team 5 Section I Bx lnyideoc 40 Tilne Historical Context Advisors and students currently do graduation planning manually Advisors usually only plan for the next quarter Current Context The market Window for this product should be quite long and there are no competing products at this time Future Context This application could possibly be extended to include interfaces to the financial aid applications and for department heads and instructors to View class interest in planning for the number of sections of courses Development Time The time to implement this project will be dependent on the following 0 Number of requirements 0 Budget as related to the number of man hours required to meet all requirements Key Stakeholders Page 5 of 5 Project Team 5 Section I Bx lnyideoc The Flatmms m wmter 1012 C0 2004 F m Dean Lemngweu39s web site Storyboards CSSE 371 Software Requirements and Specification Steve Chenoweth RoseHulman Institute September 14 2004 In the book This is Ch 13 Yes let s try some storyboarding Do it rst Then the lessons might sound familiar 1 Exterior urban fret39tThere is omeone standing on 1 corner Get Ollt a Sheet Ofpaper 2 Aermx the street a door opens mu 1 second person and something to draw with L mcrs vs 3 The second person crosses the street to the rst In 25 minutes sketch the story shown at right PCI39VHL 4 They exchange something Pass It t0 your left 5 They leave either together or apart In 25 min create a new story about the pictures you see and write it on the paper Return it to the sketcher From the book om word to image storyboarding and the lmmaking process by Marcie Begleiter Michael Weise Productions 2001 ISBN 0941188 28 02p 78 What s the book sav Outline Key points Purpose Elicit Yes But reactlons Passive active amp interactive Identify players explain what happens amp how Storyboards should be sketchy A place to add innovative content Above right At the forefront of innovative content interactivity is valuable only if it is userfriendly From Get the idea from some Storyboard Examples From the movie industry at evmlmn zml n pllmaouudocan mama N mpoa I Anyone know this movie 4 Storyboard Examples cntd More movies This one s from Blade Runner In the movie industry storyboarders don t think they get enough credit See WWWtipjarcom dancolombahtm Storvboard Examples cntd A65 W wuau mm M a u 54 15 39 51 g a i 0 Emma f 1m qmril More movies Ace V 3 Ventura When Nature Calls Complued storyboard page Art men Wbrn Nrmm 6qu Jim Carrey says We can t show the real scene on this one From 6 Storyboard from Storyboarding 101 by James O Fraioli Michael Weise Productions 2000 ISBN 0941188256 Storyboard Examples cntd There s lots of other stuff out there like storyboards from which you can get ideas Like Manga This is a scene from Kare Kano His amp Her Circumstances text translated into German Storyboard Examples cntd Or the funny papers MOM WONT LET US GO TO CAN WE HAT MOMAND N FACT AFTER THEY EAVE WATCH W DAD DONT KNOH LET S GET N THE OTHER I GUESS WE RE ON OUR 39 ONN TOMGHT WONT HURT EM CAR AND LEARHTO DRNE 63 REAH T Storyboard Examples cntd Handheld mp3 player design by Mark Hazell from WWWartsholecouk markhazellhtm n Storyboard Examples cntd From software amp web Multimedia Storyboard 9 quotW W u Wm quot mw g Eii rf Sevelopment Thls one s mmm wwm a w m Understandmg your quotMquot Stmnlgmf mcm automobile at Ma ipsadquot Muava ark A 1 39b39w 43 m miiiia39blni Mmnm gz SQQIMHMIA WVI 19 m 1b IraHi You can check out their website for more about C QTW wwvw mmm their methodology Ideas on how to do these From a book on Visual language Storyboards are an example of using the Visual for multiple purposes Audience focus Designer focus And breadth in both FIGURE 229 Update of the design process Rhetorical Situation Audience Purpose Context 096 A Visual Language Cognate Strategies Arrangement Clarity Tone Emphasis Conciseness Ethos Guides for Strategies Perception Visual Empirical Gestalt conventions research From Designing Visual Language by Charles Bostelnick and David D Roberts 1 1 Allyn and Bacon 1998 ISBN 0205200222 p 42 Ideas on how to do these Here s the original assignment you did as presented to people learning to do movie storyboards Notice there s a little more to it quotI was insecure at rst on Boxcar Bert a because I had been red from The Honeymoon Killers in 1968 after one week of shooting and for a pretty good reason too It was a zoo page script and I was shoot ing everything in master shots with no coverage because I was an artist Of course not every scene was shot from one angle but too many of them were so there was no way of avoiding a lm that was four hours long That was a great lesson From 1968 to 1972 I was very much afraid that I would get red again So when I started Boxcar Bertha I drew every scene about 500 pictures altogether Martin Scorsese Starsese on Scorsese All ol39this i thcorttiral until you try it till vourv scll aml we win workx rm yourrht following t m outlines a short mnplc ctnc itliout tlialugug that you can rm to pl39dt ucc htw itlcas Exercise The Storyboard Moment An Exercise for Creating a Coordinated Shot List Overhead Diagram and Storyboard Fmquot tlit lixllmving ltnl39t mic work out an mor lll l l tlnnr1nia shot ll L nnl iina w for a IILl i hot ctlucnt c Mark it c icra positnnh and character bloclt39iniy on the ovcrhc l ind bi turt to C tht Jllil itsWt humor each ulAlltc lramtx 1 Exterior urban trtctThcrc n mmmnt minding on a Corncr 2 Arm thc lI CCI a tloor opens and a wound ptrson t nlcrgcs 3 The L39L39mltl permquot LTK thc rtrccr to tltc rim person 4 Thct exchange unwilling 5 Thu Icaw cithcr together or apart Nollcr that llc tlcxt ription lat ks lt lilllY0ll need to add the story to l1l llt it i kk r A lm noir l ecitic on the gentler of wet romantic CUIIIL L lltt Clnrafterx tlic taintthingquot that they exchange and kclctal structure col fret to embellish the story Haw tint and don39t worry about the tll VillgjlSl llhk thn exercise to become l39 ii iar with l lL process ol39 working from a shot list and overhead in planning your imagery A student example ol39thc Storyboard Monicnt follows ovER HEAD H007Ne pm CW LIGHT Ideas on g A how to do these And here s one student s solution Part1 Student example The Storyboard Moment project Roger Lee 13 One student s solution Ideas on how to do these cntd Part 2 1 3 4 5 6 7 8 9 10 12 13 Shot List The Storyboard Moment A frontal long shot of a man quotAquot The man quotAquot is walking toward the camera A frontal Med low angle shot of a man A man who wears a nice suit is standing in front of a car A POV of the man quotBquot A frontal Med eye level shot of the man quotAquot A OTS of the man A frontal long shot of the man quotBquot Shot on a cu of the man 8quot As he turns his head camera PAN right a little End shot a cu of the man A frontal Med shot of the signal light light changes from green to red A frontal long low angle shot of a train The train runs toward the camera A OTS of the man As the train runs across the frame we cannot see the man quotAquot A frontal wide low a is shot of the train Camera PAN left to show a man in the train who wears t e hat He drops a bottle out of the window Open short on a wide rear 34 e level angle of the man quotAquot the man quotAquot watch the back of the train n right side we can see the man quot Camera is TRAVELING to the back side of the man quotAquot End shot on a OTS of the man A frontal full figure of the man quotBquot A frontal high angle of two shot of two men the man Aquotwalks toward the camera A frontal Med angle of the man B As the man quotAquot walks into the frame from right side camera changes focus to the man quotAquot End shot on a profile extreme cu of the man quotAquot A frontal Med shot of the man A On the left side of frame we also can see the long shot of the man B The man quotAquot put his left hand into his jacket A frontal cm of the man quotA39 s hand which holds the Dottie Ideas on how to do these One student s solution cntd Part3 Student example a Storyboard Moment sketches of 14 shots see page 80 15 The ins and outs of problem statements In this document we answer the following three questions 1 What is a problem statement and what s it good for 2 What exactly does a problem statement look like 3 What s a good process for deriving a problem statement which will prove valuable to us during development We believe that the creation of problem statements is crucial to the success of any project which has sufficient technical or organizational complexity You will have several opportunities to create and evaluate problem statements in CSSE 371 Requirements Engineering and also in CSSE 374 Software Architecture Usually both requirements engineers and also architects are involved in the creation of problem statements 1 What is a problem statement a Fquot 0 Problem Statement Guide Short and t0 the point A l 7 3 page statement which everyone on an engineering project agrees with saying This is what we are doing By everyone we mean official project stakeholders developers and everyone else who should have some sayso in the project s outcome A translation The problem statement translates the business case point of View of marketing people into the terminology and form used by the technical team who will develop a system as a solution to a problem or need by paying customers The problem statement will help those in business oriented nontechnical jobs communicate effectively with the technical communities that support them and help the technical communities understand prioritize and delineate among needs differentiators and wishlists It will also improve decision making speed and reduce rework resulting from a misunderstanding of the underlying reasons for what is requested by the product management team These are all reasons why it s worthwhile to do this problem statement Stays away from solving the problem The problem statement says What has to be done for a development project to succeed 7 to meet the needs of its stakeholders who are external to the development It does not say H ow that has to be done unless those external stakeholders say so This makes the problem statement become a tool for the development team to envision architectural and technology choices Specifically the problem statement matches an architectural document created by the architects for the project 7 that architecture document which follows will then say point by point how the proposed overall system design will meet the needs described in the problem statement Since both the problem statement and architectural document are fairly short they have an impedance match which enables the 3 September 2003 1 3 1 D architectural document to convince stakeholders of the viability of the proposed technical solution Something done separately It is not a part of a larger requirements document because it is a more conceptual document and is intended for a very wide audience Also the problem statement usually needs to be done first so that the requirements re ect the concepts described in the problem statement Thus the problem statement does not fit in with the schedule of creation and organizational approvals for the related thick requirements document More than just the short list of requirements Furthermore this is not just a consolidation of detailed requirements The problem statement must say for example which really are the key requirements and which ones are less important something a requirements document may not say at all And the problem statement explains why those are important to the success of the stakeholders Serves a crucial role in software project success In other words the problem statement is a format or tool for the 39 39 39 J and J v l p to 39 in concise plain language about what tasks are being paid for and what must be accomplished conceptually for the project to be a success It is something everyone involved can tape on their office wall and know When we have done this we made it Notice in the template for the problem statement below there is a place for stakeholders to signoff on this document This is very important The problem statement forces all parties involved including the development team s leaders to reach a conceptual agreement about what they are doing and sign their names to this agreement 2 What exactly does a problem statement look like Here is one sample format which you can use as a template Problem Statement for ltname of projectgt under each heading below is described the nature of the contents of that section Overall it should sound like the answer to our question What is a problem statement above Problem Statement Guide 3 September 2003 2 High Level Problem Summary Elevator statem ent 1 the issue describing the problem to be solved a single sentence that captures the essence of Summary of Primary Success Criteria How we will know when we ve succeeded A bullet list of the 35 key indicators of success prioritized metrics for things such as speed to market market dominance quality reusability Scope A short high level description of the problem boundaries 7 what is considered to be inside and outside the system for this particular release This is crucial to success 7 many projects fail because of a failure in mutual understanding of project boundaries Detailed Problem Statement FUNCTION2 What the solution must do and how it will be used identifies key features and prioritizes needs Key Business features A bullet list of the features that provide business value for the system the ones the end users care about Key Enabling Features3 A bullet list of the administrative features necessary to provision4 the system and keep it up and running the ones the administrators care about Key Concurrency Issues Which key functions must happen at the same time FORM The form the system must take in providing the functional features Form requirements have a major impact on the architecture style chosen Think What shape is the software in terms the stakeholders can understand So you might say here that it s going to have to be an Oracle based system if that s really a requirement and not a design choice But you wouldn t say We re going to use abstract factory or even it will be a clientserver system because these are pretty far into design even if there s a chance all the nontechnical stakeholders would understand you Here are some further examples of topics you could cover under Form depending of course on which ones are important enough to merit that 1 An elevator statement is the message you would want to tell a stakeholder about your project if you got on an elevator together and they asked So what s this project all about and you had till they got off to explain the key points 2 The Function 7 Form 7 Economy 7 Time model is used here for describing the problem This model is due to the US architectural firm CRSS now part of HOK See William Pena s Problem Seeking An Architectural Programming Primer Third Edition AIA Press 1987 ISBN 0913962872 3 Specifically what Administrative and Operational features must be included the activities which must be done behind the scenes or invisible to endusers 4 Provisioning means supplying the system with data For example when a new account is created something has to happen to capture all the related data verify it and get it into a system s database Problem Statement Guide 3 September 2003 3 Key Attributes The illities that impact architecture style and their priorities In each case what you want to say here is what the system has to be not what you think it will do For example under performance and capacity has somebody said how many transactions per hour the system has to do I Performance amp capacity I Reliability amp availability I Usability I Security I Modifiability maintainability amp customizability I Testability I Safety5 Note that the first six of these above are also famously the attributes at the center of the software architecture book we use in CSSE374 Software Architecture in Practice 2ndEditz390n by Len Bass et all These six are called Quality Attributes by Bass They are also seen in the Supplementary Spec template we use in senior project and other classes Hardware amp Software Constraints This includes the hardware software and customer environment within which the system will operate such as constraints such as tools and languages used for implementation hardware platforms Key Interfaces The offer amp network infrastructure external systems that provide or receive information from the system Required data formats or shared data needs Required Standards Constraints on the solution such as environmental standards interface specifications Domain A description of the product line or product family the solution is a part of key commonalities and variabilities for this particular problem Again these only go in the problem statement if they are specified as requirements If they are design choices they belong in an architecture document ECONOMY The expected value and cost of the solution to customers and to your own organization parent company etc 7 beyond your own development group can include benefits market strategies COGS6 variable pricing strategies resource constraints Business Context Overview of the business problem you are solving for the customers and the market drivers7 which impact the need for a solution to the problem Additional details can be in the appendix 5 There could be many more of these ilities which are attributes of the whole system you are creating They are sonamed because many of them like reliability and usability have that word ending 6 COGS Cost of Goods Sold In accounting this is the direct cost attributable to a specific item being sold For software this is often seen as the total cost of development divided by the number of units of that software which you expect to sell Market drivers are the key wants and needs of the market for this product which we believe will make it salable in that market Problem Statement Guide 3 September 2003 4 I Value proposition8 I Customer willingness to pay Customer Organization Constraints The people who will use the solution includes constraints on geographic location skill sets internalexternal reporting structures Development Organization Constraints9 The people who will develop the solution includes constraints on geographic location skill sets internalexternal reporting structures Development organization s available budget expected cost for solution Key Risks and Uncertainty Issues that will affect the economic success or failure of the solution TIME The relationship of the solution to past present and future This includes what the system is replacing the proposed lifecycle of the product the current market window Historical Context What products or manual system this system is replacing a view of the offer and network level system it will exist in Current Context Market Window10 both for the development organization and for customers schedule dependencies key competitors and their schedules Future Context Product Line or Product Family Direction and how this product fits into that larger set How will the solution need to change in the future 8 The Value proposition says why people will find value in the product we are developing above and beyond its costs to them The difference here is financially their incentive to buy the product 9 To the extent a problem statement includes development organization constraints it drifts from describing purely the problem at hand For example our development organization may have database experience only with Oracle and so our development has to target an Oraclebased solution However competing organizations may be able to use some less expensive database resulting in a more widely marketable product By including Must be Oracle based in our problem statement those reading it may lose sight of other options which could impact the longterm success of this project 10 Market Window is a business term for the length of time usually a range of months during which we believe a product solving this problem would be salable to the marketplace described Problem Statement Guide 3 September 2003 5 Key Stakeholders some possibilities Name Client owner of the budget 7 in a large Signature company typically an executive Names Other outside organizations which need to Signature signo Name Program Management O er Signature Management etc 7 your marketing people Name Product Management someone above the Signature project s own development manager who represents the Client infrequent decision making 7 owns responsibility for the product s success to the Client Name Requirements Engineering may go under Signature other names like Systems Engineering Name Architecture may be a part of Signature development Name Development i e your development Signature manager Name Integration and Field Support Signature representing the aftersale support people Name Testing QA etc which may be a separate signature organization especially for customer acceptance testing Name Development Management Project signature Management Name CustomerRepresentative external to your signature company 7 especially needed ifthere is a single buyer of your software product Revision History Date Version Reason for change XxXXXXXX 01 Draft XxXXXXXX 10 Baseline Stakeholder review comments Etc Problem Statement Guide APPENDIX 3 September 2003 Edited By Author s Nam es Author s Nam es Sample Appendix Glossary AcronymTerm De nition Additional Background and Context Information as available may include history description of conditions under which the project is being done things which could change etc Samples Current Customers amp Contractual Comm itm ents Potential Custom ers Key Competitors Market Drivers Technology Drivers Future Direction Current Assumptions Custom er names key attributes schedule requirements key attributes schedule requirements names if known Competitor names key strengths key markets market share Market expectations and changes that impact the problem and solution HW and SW changes tool and process changes impacting this solution Things that are likely to change in the future 7 not part of the current plan but likely Where you don t know the exact need or requirement the best guess made and if applicable why you made it 3 What s a good process for deriving a problem statement which will prove valuable to us during development Here s an example The steps and deliverables include the following Gathering Written Input Business case information or rst rough draft of the Product Technology Roadmap based on market and technology directions covering at least the next 2 years N Group Activity 1 Problem Statement Stakeholder Session background phone calls followed by a facilitated session11 with the business and technical stakeholders to 11 With the requirements engineer or system architect typically serving as the trained meeting facilitator Problem Statement Guide 3 September 2003 7 E 4 509080 identify the needs priorities and success criteria for the product Participants represent all aspects of the product life cycle from product management through deployment and customer support Representatives of key customers for the overall platform need to be included 12 Identifying the right people is part of the service Writing It At the conclusion of such an initial session someone has to sit down and write a straw horse Problem Statement 13 Group Activity 2 Facilitation and consultation with key product managers systems engineers and lead developers to develop next iteration of Problem Statement that incorporates input from key stakeholders Revising It 7 Based on the additional input Group Activity 3 Review of Problem Statement by representative stakeholders Revising It Again Updating of the Problem Statement based on review ndings Sign Offs Everyone agrees this is the concise statement of what has to be done Maintenance Ongoing validation and maintenance of the Problem Statement It can t afford to become obsolete For example there can be changes in market drivers This activity will go on throughout the development project For this effort to be successful enough of the stakeholders must be involved A typical group participating in creation of the Problem Statement for a real commercial project may include the following for our term project these numbers will be scaled down 9 O O O O O O 1 requirements engineer systems engineer owns Problem Statement and participates in Roadmapping training and all Problem Statement activities 1 architect or lead developer coauthors Problem Statement and participates in Roadmapping training and all Problem Statement activities Key product managers participate in Problem Statement stakeholder session 12 day and review 12 day Key development team members from each lifecycle phase participate in Problem Statement stakeholder session 12 day and review 12 day Key internal application customer representatives participate in Problem Statement stakeholder session 12 day and review 12 day Project Executive client participate in Problem Statement stakeholder session 12 day and optionally in the Problem Statement review Other product managers and development team members participate as needed for information gathering and input 12 Often a single development is a branch off a main product or platform and the people representing the other related pieces of software are considered stakeholders in the new project 1 An initial version for everyone else to throw darts at Problem Statement Guide 3 September 2003 8 Commonality Analysis for Sandwich Manufacture Groucho Marx Chico Marx Harpo Marx INTRODUCTION The basic functionality of sandwich manufacture has remained constant for over 2 centuries In order to reduce costs and improve reliability we offer here an analysis of the common and vari able parts of the process It is hoped that the common operations may be automated in the future OVERVIEW Sandwich manufacture can be separated into at least three subdomains bread preparation content lling and slicing We will discuss each of these subdomains in this document This commonality analysis will address the following related issues What are bread types What are valid llings for sandwiches DEFINITIONS staple food made from our or meal mixed with a liquid usually combined process of creating a sandwich COMMONALITIES The following statements are basic assumptions about the domain of sandwich manufacture 11 General Cl All sandwiches have at least 2 slices of bread of the same type 11 Breads C2 All breads used in sandwiches are sliced to thicknesses between 05 and 15 inches C3 Every bread slice used in a sandwich has an outside and an inside ll Fillings C2 Fillings for sandwiches may be divided into 2 categories a meats b cheeses VARIABILITIES The following statements describe how sandwich manufacture may vary 11 General VI A sandwich may have 2 or 3 slices of bread ll Breads V2 The type of bread used in a sandwich may vary according to type a white b rye pumpernickel ll Fillings V2 The type of meat used in a sandwich may be any of the following a ham b roast beef pastrami V2 The type of cheese used in a sandwich may be any ofthe following a American b Swiss provolone PARAMETERS OF VARIATION The following parameters characterize the variabilities allowed in the domain of sandwich manu Parameter amp Meaning Domain Default count of slices of 3 type of bread in the rye pum type of meat in the roast beef amount of meat in the Real measured in type of cheese in the Swiss of cheese in the Real measured in ISSUES The following are key issues considered during the commonality analysis Issue 1 Is a sub a sandwich Resolution No Issue 2 Can the slices of bread used in a sandwich be of different types Al Yesthere is no reason to constrain the types of bread A2 Nonmixed bread types leads to insanity Dl This might be necessary if there are insufficient quantities of one type of bread D2 Mom said that you should not do this Resolution No by vote Issue 1 Can more than one type of meat or cheese be included in a sandwich Dl Harpo will research this issue and report back TO DO 1 Add more bread types such as whole wheat Harpo Add variability for amounts of llings Chico Revisit the different bread type issue Can the slices of bread used in a sandwich be of different types on page 3 ask more moms Groucho 9 ACKNOWLEDGMENTS The authors wish to thank the following people for their valuable contributions Zeppo Marx Gummo Marx and the Earl of Sandwich
Are you sure you want to buy this material for
You're already Subscribed!
Looks like you've already subscribed to StudySoup, you won't need to purchase another subscription to get this material. To access this material simply click 'View Full Document'