Having a close relationship with the customer is always a good idea. But with that relationship comes risks. Most projects could use a knight in shining armor to protect their product's future. Discover how a product champion can help your organization stay focused on the customer without losing sight of the big picture.
Instead of wading through requirements documents, try drawing them instead. Learn about three simple diagrams and how to turn them quickly into valuable models. The diagrams presented here represent the most commonly used types for each of the three software dimension perspectives: data flow diagrams for function, class diagrams for information, and state transition diagrams for behavior.
This application tool allows non-programmers to produce working prototypes of Windows, or Web-based, database-driven applications. Read on to find out how this new tool makes protoyping a viable part of the IT software development process.
Translating customer requests into software requires exploration, learning, and discovery. As such, this Reference Point lists resources you can use to learn more about requirements exploration and modeling. Ellen Gottesdiener—a recognized authority on software requirements—provides her top recommendations for books, journals, and online resources on the subject.
Darren Pulsipher looks at Visual Modeling with Rational Rose. He concludes: "Rose is far from the perfect Visual Modeling tool, but it is definitely one of the best OO tools on the market, and the most popular. Rational Software has done a great job in supporting its tools with user conferences, training, professional services, and seminars."
While working at a telecommunications company, Linda Hamm had the task of developing and automating tests in a very short time with high-quality expectations. One of the projects was a rule-based expert system for switch maintenance. To help nail down the requirements, the group wrote state diagrams. This article is about what they are and how the group used them.
The kind of collaboration that Extreme Programming engenders can benefit both publications and development. Writing, like programming, is a naturally iterative, revisionary process. Dana De Witt Luther shares what she's learned about documenting an Extreme Programming project, using iterative planning meetings and story cards.
This article takes you from “what happens before Lo-Fi Design” (understand the user) to storyboarding (with post-it notes), through final implementation. Other steps include window design (get out the scissors) and simulated execution. This thorough, step-by-step explanation of design method is supplemented with graphics and a usability sidebar.