Flow Diagram Fun
Jonathan Babcock says:
The Beatles’ “Hey Jude” in diagram form. Not bad.
 | thanked estherderby for the clip Lining Up Priorities |
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
This is an interesting view that I hadn’t considered before. Will Google’s current way of delivering software translate to success in these arena’s, or will they need to break out of “continuous beta” mode to see success?
It will be interesting to check back and see how this plays out.
if Google wants to succeed in smartphones and business applications then it’s going to have to create dedicated teams/departments within Google that are much more process-oriented and focused on product quality from end-to-end. The never-ending beta is not going to cut it in the smartphone world or the enterprise IT worldRead more at blogs.techrepublic.com.com
Interestingly enough, the quote is about agile methodologies.
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.
I just liked this. Hooray for things that we want to do, that we do well, and that we can be paid for doing!
