Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I'm inheriting a bunch of programs at work where the original author used Microsoft Visual Studio's data components (where a dataset, data adaptor, etc) are creating inside the design environment (from the toolbox or using wizards). This yields some semi-tailored (specialized for the data) classes, and also puts the SQL code into designer generated classes.
This is not how I'm used to doing things (I've always preferred to either unambiguously have a dataset, or create my own specialized class to hold the data and hide the complexity of the underlying data layer).
Does anyone have some good insight or links discussing the pros and cons of using Visual Studio data components?
(A side note, the original author also didn't comment very thoroughly and wrote, for my tastes, a bit too much "clever" code that is not easily interpreted, so I'm not inclined to think he knows any better than I.)
I suppose another way of asking is this: Does using the data designer components result in code that is "following best practices" and is maintainable, etc? It doesn't seem so to me, but I'm looking for input from experts.
[EDIT: Added some more context for clarification of intent]
If I'm right (and it looks like I am) about using designer components really being best suited for prototypes, etc, then I'm going to have to go have some tough conversations with the original developers and my manager. So I'd like to add more emphasis on "links discussing pros and cons" part of my question... I'm looking for something substantial I can use to support my claims that this style of development / code isn't the most appropriate for production use... Thanks.
In general visual components are for throwaway applications, POC's and spike applications, i.e. prototyping. This is for a couple of reasons; they are very quick to get together but a complete nightmare to maintain. I'm unsure of the size of your application but if it were me I would be arguing that in it's current form the cost of ownership will increase with time and therefore would look to more of a DDD style of development. Bin the data layer and replace it with a good solid ORM; NHibernate(preferred) or Entity Framework 4 (easier to get into). Drop that 'clever code' and start using the Kiss, Yagni, dry mantra. It might be difficult to get them to see the light but once it starts costing less they'll love you for it ;)
If you want some more reading in this area look at the following:
Skill Matter are a training facility that run open session and loads of podcast you can watch
A good book for both Dev's and managers to read is Ship IT, it looks at good project practices. As does anything on the pragmatic bookshelf
Martin Fowlers' blog for all thing DDD
Ayende's blog is great place for all things NHibernate
stackoverflow.com, this place rocks
VS data components purpose is rapid application development. From this point of view you can see its pros and cons:
pros: fast development, do not require much coding and knowledge. Good for small applications which will not be changed in a future.
cons: breaks Layer application design logic (add here all pros of such design) combining all in one file.
As a result almost impossible to replace datasource dynamically. Makes more complicated large application support. DI, TDD - it something mysterious using it.
Actually it's a very wide question.
I'd recommend to read more about N-tier application development and Test Driven Development
Hope this help
I wouldn't even go so far as to say that the designer DB components are good for POCs or prototyping. Those components are in Visual Studio primarily as a sales pitch for the framework, so that Microsoft can say "wow, look how easy it is to create a data-driven application with .NET!" They should have been removed years ago, IMHO.
However, don't confuse the designer components with ADO.NET (i.e. DataTables, DataSets, DataReaders, DataAdapters etc.) itself. Since the app you've inherited was built around the designer components, that means that it was also fundamentally built around the ADO.NET components. You can (and should) get rid of the designer components, but you shouldn't necessarily get rid of ADO.NET as well.
I personally think you are definitely on the right track, BUT imho it really depends on what you already have and what the plans are for the future of the product.
I have seen production code that uses just as you are talking about and works fine, and is somewhat easily maintainable.
There are even some great drop in modules from very large companies such as Telerik that fall into the same category of development that you are talking about.
I think what really is an important factor to your employer is: what can you use to get the job done in the fastest most efficient way. I would say that in general though, the "drag and drop" tools straight out of the box are not very good for long term enterprise level applications.
Here is an article by Charles Petzold that may provide more "expert" credential information for you.
http://www.charlespetzold.com/etc/DoesVisualStudioRotTheMind.html
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I work in a company where, since I arrived, I had full freedom to use whatever Microsoft technology, pattern and tool in order to develop my applications.
I started to develop all the applications with ASP.NET MVC3 and I currently have 5 applications deployed and working.
The other day I had a meeting with my manager to review all the applications and he realized that my code was completely different than what he expected. He basically realized that I do not use Web Forms and that I use MVC instead. He thought he was just some component/tool and not a totally different approach to programming. He was curious and he briefly studied what ASP.NET MVC was.
After two days he said that I need to convert all the applications to Web Forms and use just Web Forms from now on. He says that MVC resembles the old asp(that for certain aspects is true) and that it takes longer time to develop the application and makes people confused when there is the need to change/maintain the application.
I think it is not true because, after a steep beginning, I got used to the magic of MVC and it eases development, componentization and maintenance of applications.
I said him that Web Forms is too coupled UI/Logic/DAL, after a while the code becomes unreadable and it jeopardizes unit testing. I also shown the possibility to replace the old GridView(one of his main concerns) with the jQuery or MVCContrib grids.
There was no way to convince him. Both for work and personal development I do not want to take a step back to Web Forms, therefore I kindly ask you to tell me the most important points that make MVC "superior" to Web Forms.
Thanks
Unfortunately, it's not uncommon for a manager to give a business-speak-laden version of "I don't understand this, so I want you to do it my way instead." This often stifles progress. (I've actually left jobs in the past for this very reason, managers who refused to allow any development that they personally didn't design.)
However, you also need to keep an open mind on the subject. He may very well have good reasons for this. Supporting the code is a big concern, and while I agree that it's easier to write clean and de-coupled code in MVC, at the same time he might be seeing a market where it's much easier/cheaper to hire farmed out developers at low cost to support a WebForms application. He may have a stack of resumes in his drawer that paint a very different picture between WebForms and MVC.
The best thing you can do, really, is approach both paradigms with a completely open mind. Understand that the rumors of WebForms' demise are greatly exaggerated. So if you really want to convince him of anything, then you're going to have to present a proper and unbiased comparison.
Start with a simple pros and cons list to compare the two paradigms. Make sure you don't skip on anything. If he has pros for WebForms and cons for MVC that you tried to ignore, that'll hurt your case. Evolve that list into some examples, demonstrations, proofs of concepts, etc. Make your argument tactile, give it numbers and tangible values that mean something real to management beyond just "this is a better development strategy." Quantify it.
If you approach this with an argument that says little more than "well, my way is better because it just is" then you're not going to get far. Even if you have a point to make, you have to successfully make that point to him. You have to put it in his language.
This is really less about which development strategy is better and more about communication and clarifying your ideas. After all, if you can't defend your position then from his perspective it's not a good position.
And if you fully clarify and quantify all of this, and it's critical that you keep an open mind about WebForms, then what you've done is given him the information he needs to make an informed decision. That decision may not change. He may still insist on WebForms. But it's his decision. What you're doing here is presenting him with all the pros and cons, all the costs and benefits (both immediate and long-term in terms of re-writing what you already have and ongoing support and all of that). If his decision turns out to be wrong, at least it will have been his informed decision. You won't have kept anything from him.
In the end, he may still insist that you do things the way he understands them. Some managers are like that. But take this as an opportunity for your career to master the art of presenting an argument. It won't be the last time you find yourself doing this.
I would search data or survey result showing superiority of MVC projects rather than telling him how good MVC is. MVC is just more productive way of creating & maintaining quality software. One thing I would like to add is that since UI is completely decoupled with biz logic, it is a lot better to automate code production with code generation tools such as T4 and MVCScaffolding.
WebForms was created to make it easy for WinForms developers to move to web. ASP.Net MVC's main benefits are that it separates out the Model (data), View (HTML,CSS,jQuery) and Controller (logic and routing). This allows different people to work on different parts if needed (separation of concerns). It also is much closer to a true web model, designing using HTML directly rather than this being abstracted away by ASP.Net User Controls. Obviously, in MVC, you have the HTML helpers and can make your own custom helper extensions as well as using DisplayFor and EditorFor templates.
The bosses argument is that many developers will know ASP.Net but not MVC, so it will be easier for others to work on it. However, MVC has been out a while now and many keen developers will have already picked this up or can do very quickly. It's a very clean and powerful way to develop web applications very quickly and easily maintainable in my opinion. ASP.Net of course has its advantages too but you asked "what makes MVC superior" so I've just argued a few benefits of MVC over ASP.Net. This is by no means an exhaustive comparison and hopefully others will add their opinions too.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
We are currently starting a bigger project. What're your suggestions for best practices of workflow?
We are planning to rebuild from scratch (the existing product is outdated by years, regarding visual and internal design and programming). While the product functions (a Rails based web project) are already set, the question is: What is your workflow from here on? The most interesting part is: How and when do you do your screen design?
We are planning to do it in the following order:
"Pencil and paper" screen design: Just layout what the screens should look like and visualize the functions and visitor pathes
Hand out the layouts from point 1 to the designers, have a talk to them, and let them work in parallel to programming on the designs
First implementation, simple color-less HTML layout based on point 1 (automated tests, functionality, BDD, TDD)
Integrate the designs with the product prototype
Work out the rough edges together with the designer team to finalize the product
Release a beta product for the customer to test
Do you have similar workflows? Are there suggestions for improvements? But the most important for me: How exactly do you do point 1?
While this is not exactly programming-related I still think this should belong on StackOverflow as this is important for anyone doing bigger projects. From the past we know that good screen design is always a critical and hard point if trying to do that while programming, and even harder to deploy it after the prototype application has been created.
Update: I found Balsamiq Mockups to be a very helpful tool to do the mockups. Still there's an open question how one would best visualize visitor pathes.
Update: We had been successful using Balsamiq Mockups to create a design pleasant to the customer and we managed to successfully integrate this into the existing web content. The customer is so comfortable with the new ideas that he is planning to redesign the complete web site.
I like your workflow. It should lead to a decent result.
A few ideas here:
Let the designers know and understand your presentation model. What pages there are, what information and control elements will they have, what is the role of each of them, what is the purpose of the page and what message should it communicate to the user. If you let the designers work alone then they will design something to reflect their vision of the project and not your design. You'll end up redoing everything or trying to adapt one part to the other.
Users will only see and understand design. They know nothing of implementation. If they see a button they will think the feature is there. if you plan to go agile while cooperating with the users during development, hide out elements that are not implemented yet. Feed them results one step at a time.
If you can have users nearby do screen design together with them in iterations. There is not much work for designers yet, when you are basically deciding on the layout. All those colourful effects and polished buttons should be done after the layout is stable. Otherwise it will be a waste of the designers work.
I really like the model of extreme programming. When dealing with new products user requirements can quickly change over time and this is a proven method which keeps the design "up to date".
Have the users write up functions that they want for the application. And have the designers agree upon a general layout.
Write up a general wire-frame that both you and the user agree upon, I like to do this in smart draw or some sort of rapid gui development platform. (no functionality at this point).
Write the code for the GUI based upon the wire-frame and write sequence diagrams and class diagrams.
Based upon these design start to fill in the functionality behind the GUI
Release betas throughout the process of adding functionality to select users who can help guide future development
The benefit of this design is that at any point in time you can re-work the GUI and incorporate new functionality. The idea is to have a general plan at the beginning that can be adapted as user requirements change.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
What comes first? After the design has been outlined and approved, should a designer create pages in HTML and then hand them to a developer to add code? Or should a developer build simple pages that work and hand them over to the designer?
I've always done the latter, but recently worked with a designer who built an entire site in HTML and handed it to me to make it work. I found it saves a lot of time for 3 reasons:
The developer doesn't have to create all the form fields and rudimentary layout.
The designer doesn't have to rework all the "ugly" pages into something attractive, instead starting with a clean site which is faster.
The code isn't accidentally broken by the designer. I've found designers are more likely to break the code doing their work than developers breaking the design adding the backend functionality.
In short, if the designer does his work first, there's very little rework. I just make what already looks great actually work.
So which is best practice? See other plusses and minuses?
EDIT: Assume both designers and developers are already in agreement on the proposed design.
Wireframe mockups and visual aides are a great way to elicit requirements from end users. Giving the user something to look at and see helps to drive the design to where it needs to go instead of developers just doing the guesswork.
Also, UI design does affect your code. I think the biggest myth that we buy into as programmers is that we can just build a business layer and then spread the UI on like peanut butter. It never happens this way, so I am a big fan of having designers work with users early on and often. Having a visual design to work against is like TDD for the UI, and it helps to drive the process downwards.
Best practice is to try it both ways, see which way works best for your organization, then do it that way.
Occasionally try it the other way to see if anything has changed.
That way you get a solution tailored to your situation without worrying about ephemeral transitory things like "best practice".
As you can probably tell, I'm not a big fan of rules being handed down from on-high. Don't get me wrong, if something proves to be an advantage, I'll use it (agile, for instance, since it focuses you on immediate deliverables). But it has to be proven in the environment you work in, otherwise it's just something that worked for someone else.
I think it depends highly on how your views and code behind are set up. Some people will put a lot of logic into their views and others will have little to none. It will eventually just come down to your specific case.
In most cases, I agree, it will be easier to create the HTML first and include the back end programming later. It is essentially making a specifications document for you.
Once you've got your storyboards all worked out and approved, it's probably more natural to do more detailed "sketching" at the HTML level first. But I guess I'd also try to decouple the design and code as much as possible, so that the developer and designer can work somewhat in parallel. Two ways of decoupling are XHTML/CSS and "unobtrusive Javascript".
The developer and designer can work out the skeletal XHTML page structures they'll need from the set of storyboards. The designer then can use static mock pages to develop the CSS style sheets and explore the artwork. Meanwhile the developer can focus on generating the XHTML structures without style information. The big advantage (and goal) of CSS was to separate page structure from page appearance.
Another avenue to explore are "unobtrusive Javascript" frameworks like jQuery, whose goal is to separate the page's behavior from its structure, again making it easier for the developer and designer to work in parallel. By parallelizing these activities, it would be possible to incrementally deliver versions of the final product, both in form and in substance.
I would definitely go with designer first. If the coder does the pages first, he's forcing a design on the designer -- particular for a multi-page form.
Depends on the type of place you work at and the skill set of your teams!!
I worked for a Design Agency for many years where designers ruled as they brought in the biggest revenue stream and the web work was an add on to the services.
We worked very closely with the designers to make sure the designs met requirements and we not to off spec. The designs were a lot of the time used as sign off (don't get me started!!) and not much could changed once agreed by the client. The designers were also not that good at HTML,JScript,CSS etc so this was left to the developers to implement.
So in this case design was always done first which worked well, even if it was for the wrong reasons.
Well, assuming that the designer produces high-quality HTML and CSS (which is far from obvious, btw), the question boils down to: do you have 100% control of your HTML or not?
If you use a CMS, or a framework that likes to produce lots of its own HTML (like ASP.NET), then you have no choice. Trying to make the output match the designer's HTML is a pointless headache. You'll be better off with your original method.
However, if you produce all of the HTML by yourself (using PHP or, say, a lightweight framework like Django), it's better for the designer to produce the HTML first, for the reasons you mentioned.
Small nitpick: I disagree with reason #2. CSS-based design is all about taking "ugly" (that is, bare and functional) pages and making them attractive, without even touching the HTML. If the developer writes decent, semantic markup, it should be pretty easy for the designer to add his design on top (well... with some HTML hacks added, like for round corners and the like), since this is what he should be doing in the first place.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm facing developing a new web app in the future and I'm wondering how to decide what framework to use. I've settled on Python as my language of choice. But there are still may frameworks to choose from! More generally how do you choose between different similar technologies that are still in the works as the latest round of web frameworks are? I'm curious what your process is for deciding on technologies you've never used.
Recognize that no choice is perfect -- or even very good.
No matter what you choose, someone will have a suggestion that -- they claim -- is better.
No matter what you choose, some part of your tech. stack will fail to live up to your expectations.
The most important thing is "shared nothing" so that the components can be replaced.
After that, the next most important thing is automatically-generated features to reduce or prevent programming.
Look at Django. Lots of automatic admin features make life very pleasant.
There are a number of things you can do:
Download the frameworks and build something similar with them for comparison.
Look for comparisons by other people, but attempt to understand the bias of the reviewer.
Observe the community at work, see what people are building and the issues they run into when using the technology. Forums, blogs, mailing list etc are good places to check out.
Go to conferences and meet like minded developers interested.
You can also take the approach of using stable versions rather than alpha bits. After a while you might move closer the bleeding edge. People associated with the project in question are generally more biased than those approaching from other platforms, be careful who you trust.
Consider the impact of using a bleeding edge framework versus an established one. Sometimes it's important to your customers that you are on one perceived as stable. At other times this doesn't matter. How comfortable are you with fixing the framework itself? Great developers will learn the internals, or at least know enough to keep things moving whilst a bug is sent to the framework mailing list etc.
Consider some general best practices in building abstractions and reusable code on the python platform. You may be able to save yourself some work in moving to another platform. However, don't be a reuse junkie as this can limit the effectiveness of your use of the framework. The 37Signals guys are right when they talk about extracting frameworks from working code rather than building frameworks from scratch.
I know this is an old posting, but I am in a similar situation (again) and I think there are other people who may want to look for different opinions, and hear of (somewhat) successful experiences.
Since baudtack mentioned Python, I will try to answer this along the lines of my experiences using Python. Here is what has been working for me:
determine the scope of your project - outlining what your application is supposed to be able to do without introducing any programming or design notes will clarify your goals greatly
determine how you would like to work with your code, stack and data:
a. what sort of programming paradigm do you want to work with? i.e. object-oriented, functional, etc. do you want to play to your programming style or do you want to follow somebody else's programming style?
b. use semantic web or not? do you want greater control over URIs and their design? (I found web.py great for this by the way - It is my choice to create REST APIs in Python)
c. do you want to be trapped by framework requirements, or do you want a better separation of the application from the web component, i.e. use a framework to utilize your application as a set of modules, for example. My problem with Django was that I ended up not programming Python, but having to learn more Django than I needed to. If that works for you, then that is the way to go.
d. data stores... some sort of SQL vs. non RDBMS (xml databases like eXist-db with full xquery support) vs. OODBMS vs. a combination of the above? how complicated do you need this to be? how much control/separation do you need to have over how data gets stored and recalled in your application?
e. testing: unit tests... thank goodness for python! if your web app has the potential to grow (as they often do), having a sane and coherent testing platform to begin with will help out a lot in the future - I wish I had learned about this earlier on. oh well... better late than never.
f. how much control over the server do you need? hosting considerations? how much control over an Apache instance do you need to have? OS specific needs? I found that using shared hosting providers like Webfaction has been great. I eventually found I needed greater needs for flexibility and bandwidth. In other words, what can you get for your budget? If you have USD50 to spend each month, it may be better to consider a virtual hosting solution like Linode....
Finally, I echo S.Lott's sentiments that no choice for a solution is perfect, and are subject to obsolescence.
Experience trumps hearsay. I've found that prototyping is a huge help. Make a prototype that uses the features you expect to be the most important for various frameworks. This helps route out any features that may not work "as advertised."
In general though, kudos for being willing to look at new technologies.
I have a set of criteria in different categories:
Activity & Documentation
Is there an active user base?
Is there an active development base?
Is the support responsive and information accessible?
Are there user and development guides and reference material?
These are essential, there needs to be traceability of all of these to build confidence in the solution.
Ease of use
Are basic features easy and complex features possible? I typically give a new framework a test drive and try to roll out a set of use cases to see how intuitive the framework is to use.
Is installation intuitive and simple for a local/dev installation and production deployment?
How is it backed up and upgraded?
What is the effort and UX for implementing a "Hello World" type blog post, static page, menu item, and plugin?
How are versions dealt with for the core & plugins?
Example (on the topic of Automated Testing/Continuous Integration solutions)
Several years ago I evaluated several Automated Testing solution. At the time Jenkins and TeamCity were front runners and in the end I chose TeamCity because of the UX, active user & development base and quality of accessible documentation.
Example (CMS for a blog)
This criteria is also why I prefer to use Wordpress over other options. While wordpress has its shortcomings, the user and development base is strong and active which leads to a software architecture with more potential to evolve over time and maintain its relevance and a development community that provides quality plugins and themes to choose from.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I have been looking for a collaborative tool for developing functional specifications. I am looking for the ability to:
Have multiple users contribute to the specification.
Provide some form of traceability, which could be done manually if needed.
Provide users with the ability to add comments and notes.
Upload and display Visio documents
Upload and display mockup screens using Balsamiq Mockup.
My initial impression is that using a wiki could be a good tool for this task. Does anyone have experience with using a wiki for creating functional specifications? What would be the pros and cons to using a tool like this as opposed to a requirements management tool?
Your input is greatly appreciated!
It's possible to do what you describe, to develop requirements in a collaborative way, in spite of using a wiki. Nothing about the wiki paradigm assists in this process.
I managed a wiki on the Zend Framework project to track proposals for components. They're still using it. Proposals are different from functional specifications, but the usage is similar enough to your question that I think this is relevant.
A wiki doesn't take care of itself. Unless you have someone responsible for managing it and making sure there is some structure and consistency, it quickly becomes a mess. The real-world analogy would be to hand each of your team a blank sheet of paper and tell them to write up their part of the requirements. Problems with this are:
Every contributor has to make up their own document structure, and write about different things in a different order. So it's impossible to compare one page to another.
There's no "index page" to organize all the disparate contributions. No one wants a page to "fall through the cracks," but in a wiki that's the default destiny of any page as soon as it's written.
There's no feedback loop to make sure the writing actually gets done.
The way to make it work is to apply some process to the project, and use the wiki in accordance with that process.
Give people the ability to create a new page in the wiki, but only through an interface that automatically links the new page into the right index.
Define a lifecycle for documents, so they are sure to be drafted, reviewed, and approved at the appropriate stages.
Provide a template for a new page. Provide the section headings that you need in each of these pages, and make part of the review process a confirmation that head section has been filled out adequately.
"What would be the pros and cons to using a tool like this as opposed to a requirements management tool?"
While it seems like a great idea, what you run into are people who can't and won't write.
People who can't write -- well -- can't write. They can't communicate with an email or a wiki or any medium outside voice.
Some people are "disorganized". Actually, writing is too linear and they don't think linearly.
Some people don't get the "write to your audience" and write stuff that's incomprehensible.
Sometimes you can't even figure out what they're talking about, much less what they're writing about. They talk in jargon or code. They don't know much but insist on being heard.
Some people won't write.
Some people refuse to make commitments. Even in a wiki where it can be retracted. They feel they must pre-discuss everything.
Some people are in the habit of doing everything by giving direction to someone else. They either don't write for themselves, or, they make people stand around in their office and listen to them talk and type.
Some people are generally toxic on any kind of project. They spring new requirements at the last minute. Their first response is "that will never work". They don't brainstorm well. When they say it work work, and you beg them for an improvement, they don't have one. They just know it won't work.
My experience is that only programmers can use a Wiki successfully. And only senior-level programmers.
N00bz don't have enough experience to sort out requirements from design from rumors and management fluff.
N00bz don't always have the language skills to write clearly. They may eventually, but one look at their Javadoc comments indicates that they're struggling with the "clarity" part of writing.
It's very appealing. I'm hoping for people to get better at using wiki's because I think it could have a lot of advantages over more traditional approaches where one person interviews everyone and writes things down. But it requires a level of confidence and skill in communication that few people seem to have.
Consider researching Fog Bugz. They tout themselves as the best of the
best for project management. Considering Joel's history I'd give them the
benefit of the doubt. They use a wiki in the way you've just described.
I would suggest signing up for the free trial, if you're serious.
Depending on the size of your project, buying it might be a very good
option.
At very least you could look at how they've structured it, or read the
forums for ideas on how to build your own stripped down version
Specialist tools help keep things on track and introduce a fixed work-flow. This is kind of the point, keeping things focused and functional. Using generic tools like a Wiki might be great for a bunch of programmers but introducing one for 'mixed-mode' work might be bad:
Things can creep and get off-track quickly
Communication can be lost in the medium
Look at things like Basecamp. They can be thought of as an applied wiki, or collaborative tool. A generic tool for specific purpose needs refining. I don't know if MediaWiki or others have enough customization to keep things clean and focused.
Maybe gather the requirements for your requirements management tool (recursive I know) and what aspects (communication aspects) you can take from the wiki culture and an open-communication mindset. If neither requirements management tools or wikis fit the bill, look at building one. Might be the next big thing. It feels like saying Could I use a wiki instead of Bugzilla?
A fixed work-flow webapp for requirements management with an open-communication emphasis that allows people from many roles to see and understand might be good!
We have used TWiki and now FosWiki in that context. There are many things one gets for free (version control, access control, Web-base access, searches, remote management, security patches, ...). In a few minutes, one can define:
a table defining requirements attributes,
which creates interactive forms with field selection and validation (where you can also document discussions and rationales, embed images, attach documents, link to other requirements...),
and then queries on these "requirements" and show them as tables that can be sorted, filtered, printed, reported against, etc. (e.g., http://jucmnav.softwareengineering.ca/ucm/bin/view/ProjetSEG/JUCMNavRequirementsVer2).
Obviously, one can easily use hyperlinks and Wiki links along the way. FosWiki also has features that can be used to enforce specific workflows, if needed. It is also easy to support forms for use cases and other paradigms (we have done this in the past, and that works generally well).
Wikis such as FosWiki are extensible and one could develop further modules for addressing weaknesses related to traceability management and impact analysis, table-based modifications of requirements, overall packaging, etc.
As a middle ground between a free-form wiki and a requirements management tool, consider using a structured wiki like Foswiki. I haven't done any formal requirements management (with a wiki or otherwise), but I have used TWiki (the predecessor to Foswiki) for other tasks, and it permits you to define a workflow, form fields, and so on as you need them, while keeping the flexibility of a wiki when you don't need a formal structure.
I agree with all (most) of the people above - use of a wiki may sound ok, but wiki's are meant to be present information and be updated as needed, not to be used as an interactive project management tool. I would strongly suggest SmartSheet (I'm a strong advocate of the product) - it provides a spreadsheet like interface where you can store multiple files per row/task, send out automated updates to users and maintain specification revisions...
The other approach could be the use of Google email, docs and calendar - a free friendly way of team interaction....I would shy away from issue/bug tracking tools for project management - they tend to have differ on focus: PM tools on the entire project/resource/timeline and Issue tracking tools for specific entered issues....
This may be a bit old now, but I am currently using Atlassian's "Confluence" and it's been great. I currently work as a UX engineer playing the role of "Product Owner" within an Agile process. I can document requirements for discrete interfaces, allow for multiple users' feedback and comments, and intertwine each interface with other interfaces within a larger context (e.g. user story). Everything is very dynamic and template driven. It's suiting my current needs very well.