Probably wouldn’t have chosen the hot dog stand example, but it works. And it’s very true. It’s much easier to start at the highest level - only considering the absolute “musts” than it is to start out in the weeds and try to pare things down from there. When you start anything new, there are forces pulling you in a variety of directions. There’s stuff you could do, the stuff you want to do, and the stuff you have to do. The stuff you have to do is where you should begin. Start at the epicenter.
For example, if you’re opening a hot dog stand, you could worry about the condiment, the cart, the name, the decoration. But the first thing you should worry about is the hot dog. The hot dogs are the epicenter. Everything else is secondary.Read more at www.leadershipnow.com |
Just a quick, helpful little quote distinguishing the two. | Data modelling and database design are two very different activities.
For data modelling, the question you are asking is :
1) What does the world being modelled look like ?
In particular, you are looking for similarities between things.
Then you identify a ’super-type’ of thing which may have sub-types.
For example, Corporate Customers and Personal Customers
|
| 2) For database design, you are answering a different question:-
how can I efficiently design a database that will support the functions of proposed application or Web Site.
The key task here is to identify similarities between entities so that you can integrate them into the
same table, usually with a ‘Type’ indicator.
For example, a Customer table, which combines all attributes of both Corporate and Personal Customers.
As a result, it is possible to spend a great deal of time breaking things out when creating a Data Model, and
then collapsing them back together when designing the corresponding database.Read more at www.databaseanswers.org |
Scott Sehlhorst is a great teacher of principles of product management and business analysis. The clips below are from his recent article on alignment of user and corporate goals. The clips are just a taste. The article includes vending machine and AT&T/iPhone examples of dissonance between user and corporate goals. When defining requirements, you always start in the context of a goal – either a user goal or a corporate goal. You need to be aware of both. Having a positive user experience is important, and requires a user-centered understanding. Achieving your corporate goals might be in conflict with some user goals. |
| When the person (user) wants to do the same things that your company wants them to do, you’re in alignment. When the user goals and corporate goals suggest different activities, you’re in conflict. |
It may be great – when the user and corporate goals are in alignment, the practical goal and associated scenario (activity) are easily defined. What about when the goals are in conflict? |
Bluepring 2010 continues the movement of requirements management tools into the requirements modeling/definition space. “Requirements have always been the bane of software development throughout the years, there’s no end of statistics that point to requirements as the weak link in software development projects,” said Higgins. |
Typically, requirements authors will resort to legal-type text documents, “one of the poorest forms of communicating,” according to Higgins. That is complicated by distributed teams with members of different cultures and backgrounds, he added. |
Among the new functionality is a business process diagramming capability so requirements authors can understand the business processes they are trying to automate in the software they are building. “We can sketch up business processes very quickly, very easily, to make sure everybody is on the same page,” said Higgins. |
Another feature tracks changes so users can compare two versions of sets of requirements, and automatically output that into document form “as if someone had authored those documents manually,” he said. Read more at www.itworldcanada.com |
Interesting thoughts on a social/open environment for requirements definition for government projects - acquisitions in particular for this article. Imagine if we opened up the requirements process to anyone who wanted to participate and did so in a transparent and collaborative forum through structured processes and Web 2.0 tools. Using the wisdom of the crowd to define requirements and the best development process, participants could propose ideas based on experience, good practices and standards; question and weed out bad ideas; build on one another’s ideas; and float the best to the top. |
Put aside for now questions about the manageability of the process, operating within the Federal Acquisition Regulation, when to apply this crowd-sourcing, open strategy, etc. Although business certainly has a financial motivation, individuals participate in peer production communities because of personal passion, a desire for recognition of their expertise or just a desire to be part of the community. |
If managed effectively, there is enormous value in co-creation and applying resources outside your borders. And imagine what this might do to attract and retain the Net Generation workforce we are always seeking out. They live and thrive in the online, collaborative, open environment. Read more at fcw.com |
Some good self-analytical questions for getting to the bottom of requirements definition problems. | What makes defining requirements such a challenge for us? Do we have the skills to write good requirements documents for complex acquisitions that enable adaptability for change during development life cycle? Are we working too hard to get requirements 100 percent right before we move forward? Are we focused on defining the “how” instead of working to define success? Are resource shortages forcing shortcuts that eventually only prolong the timeline and costs and increase the risk of failure? |
| And the final question: Would making the requirements development process more open, collaborative and transparent help?Read more at fcw.com |
Requirements Object Model from Seilevel. I like models that show the relationships between requirement types and the progression from one to type to the next.
| Many
types of requirements crop up again and again, no matter what a
particular new system is for. The idea of requirement patterns is to
provide guidance on how to specify common types of requirements, to
make it quicker and easier to write them, and to improve the quality of
those requirements. A requirement pattern is applied at the level of an
individual requirement: to explain how to write a requirement of that
type. |
Really interesting description of how images and words describe ideas.
Wang Bi, a third-century Chinese scholar, has this to say in “General Remarks on the Changes of the Zhou”:
|
Images are the means to express ideas. Words are the means to explain the images. To yield up ideas completely, there is nothing better than images, and to yield up the meaning of images, there is nothing better than words.
|
| In other words, he suggests that to capture ideas from the problem space, we need both imaging tools and descriptive tools.Read more at www.ddj.com |
|
