We just completed a series of articles detailing how to use Use Case Points for software cost estimation. In this article we have a free MS Excel Spreadsheet for calculating use case points. Download it today to make it easier to do your project cost estimations.
Business Analysis / Product Management / Project Management / Requirements / Requirements Models / Use Cases
Posted on:
Software Cost Estimation With Use Case Points – Final Calculations
The final step in project cost estimation with use case points is to do the math. First you identify the technical and environmental factors that influence your environment and describe your team. Then you analyze the use cases and actors that describe the expectations of the software and who has them. Finally, you bring it all together to do the math.
Business Analysis / Product Management / Project Management / Requirements / Requirements Models / Use Cases
Posted on:
Software Cost Estimation With Use Case Points – Actor Analysis
Software project cost estimation using use case points takes the approach of estimating the amount of effort based upon what the software is being asked to do – not an analysis of how someone chooses to do it. We’ve looked at technical and environmental factors that influence our estimate. And we’ve done a use case analysis to quantify how much work the software is being asked to do. The last area of analysis focuses on the users of the software.
Business Analysis / Product Management / Project Management / Requirements / Requirements Models / Use Cases
Posted on:
Software Cost Estimation With Use Case Points – Use Case Analysis
Software cost estimation with use case points is primarily driven by use case analysis. You take into account environmental and technical factors, but they are ultimately only modifiers of the analysis done on the use cases. Each use case contributes to the project cost estimate, and use cases of varying complexity have a varying influence on the cost estimate.
Flashback
Posted on:
Flashback: A Year Ago This Week on Tyner Blain [2005-12-10]
A look back at the best from a year ago.
Prioritization / Requirements / Slightly off-topic
Posted on:
Prioritize With Poe – Halloween Fun
A little Halloween fun – an homage to Edgar Allen Poe describing this week’s issue triage and prioritization meeting.
Communication / Requirements / Requirements gathering / Writing
Posted on:
Monty Python and Software Requirements
The Monty Python troupe helps us remember five (no, three sir!) things about software requirements. And now for something completely different…
Business Process Modeling / Product Management / Requirements / Requirements gathering
Posted on:
Business Rules And Requirements
What is the difference between a business rule and a business requirement? Does the difference matter? A business requirement is something that is multi-customer, and a business rule represents a single customer’s approach to meeting that requirement. Product managers and analysts care about both, but product managers emphasize requirements, and analysts focus more on rules.
Business Analysis / Product Management / Requirements / Software requirements specification
Posted on:
Writing For The Purpose of Reading
The reason we write is so that someone can read it in the future. Duh. When we’re writing requirements documents, or documenting processes, how often do we stop and think about who will be reading our documents? We need to make sure our writing will be easy to read for our audience.